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ABSTRACT 


The  proliferation  of  Unmanned  Aerial  Systems  (UASs)  and  laek  of  mandated 
standards  has  led  to  unique  Unmanned  Aerial  Vehicle  (UAV)  and  Ground  Control 
Station  (GCS)  designs.  A  former  Under  Secretary  of  Defense  for  Acquisition, 
Technology,  and  Logistics,  stated  in  an  Acquisition  Decision  Memorandum  (ADM)  that 
UAS  GCS  commonality  could  reduce  manpower,  procurement,  sustainment  and  life 
cycle  costs.  While  the  ADM  provided  an  impetus  for  commonality,  it  did  not  define  a 
path.  This  project  defines  a  common  GCS  functional  architecture  that  provides  the  first 
steps  on  the  path  to  UAS  commonality.  Stakeholder  documentation  was  analyzed  to 
identify  areas  of  greatest  concern  and  to  examine  previous  efforts  in  this  domain.  Then,  a 
tailored  systems  engineering  process  was  employed  to  develop  a  new  set  of  requirements 
which  includes  a  common  Air  Vehicle  Operator  (AVO)  Human-Machine  Interface. 
These  requirements  enabled  the  creation  of  an  innovative  functional  architecture  for  a 
common  GCS  concept.  The  utilization  of  this  architecture  has  multiple  operational, 
logistical,  and  financial  benefits.  This  project  quantified  AVO  training  cost  benefits  and 
found  that  implementation  of  the  common  GCS  architecture  in  accordance  with  the 
derived  requirements  will  benefit  the  Department  of  Defense  through  reduced  Operations 
and  Support  costs  and  increased  operational  capability. 
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EXECUTIVE  SUMMARY 


The  proliferation  of  Unmanned  Aerial  Systems  (UASs)  and  lack  of  mandated 
standards  has  led  to  unique  Unmanned  Aerial  Vehicle  (UAV)  and  Ground  Control 
Station  (GCS)  designs.  A  former  Under  Secretary  of  Defense  for  Acquisition, 
Technology,  and  Logistics,  stated  in  a  2009  Acquisition  Decision  Memorandum  (ADM) 
that  commonality  in  UAS  GCSs  would  reduce  Department  of  Defense  (DoD)  acquisition 
manpower,  procurement,  sustainment,  and  life-cycle  costs.  He  went  on  to  profess  that 
increased  commonality  could  improve  interoperability  for  joint  and  combined  UAS 
operations.  This  project  develops  twelve  necessary  UAS  requirements  to  produce  a 
proposed  functional  architecture  for  a  common  GCS.  This  architecture  enables  greater 
commonality  and  interoperability  among  UASs.  Additionally,  it  was  determined  that 
cost  savings  could  be  realized  by  implementing  this  common  GCS  concept. 

To  approach  the  problem,  a  tailored  systems  engineering  process  was 
implemented.  The  first  step  included  information  gathering  to  obtain  background  data 
about  existing  and  proposed  UASs  and  commonality  concepts.  This  phase  explored  UAS 
Integrated  Roadmaps,  Government  Accountability  Office  (GAO)  reports.  North  Atlantic 
Treaty  Organization  (NATO)  Standard  Agreement  (STANAG)  documents,  and  the  ADM 
that  initially  called  for  GCS  commonality.  The  UAS  Integrated  Roadmap,  various  GAO 
reports,  and  the  previously  discussed  ADM  all  call  for  increased  commonality  between 
both  inter-service  and  intra-service  GCS  designs.  These  documents  surmised  that  such 
goals  could  be  met  with  the  use  of  modular,  open  source,  standardized  systems.  A  survey 
of  current  GCSs  clearly  indicates  a  lack  of  commonality  across  the  DoD  and  illustrates 
the  problems  resulting  Ifom  such  an  uncoordinated  development  approach.  Even  UASs 
of  similar  sizes  and  missions  utilize  non-standard  control  systems  that  do  not  facilitate 
commonality  or  interoperability.  A  review  of  literature  has  revealed  that  UAS 
commonality  is  desired,  but  no  guidelines  for  implementation  have  been  provided. 

Next,  stakeholder  feedback  was  gathered,  and  background  information  was 
utilized  to  scope  the  direction  of  the  project.  This  led  to  a  focus  on  the  need  for  a 
common  Human-Machine  Interface  (HMI)  for  the  air  vehicle  control  functions  of  Groups 


XI 


3-5  UASs.  Additionally,  the  project  was  limited  to  Department  of  Navy  (DoN)  assets 
due  to  information  accessibility  and  Naval  Air  Systems  Command  (NAVAIR) 
recommendations.  Further  scoping  limited  the  quantitative  benefits  analysis  to 
Operations  and  Support  (O&S)  costs  for  training  UAS  Air  Vehicle  Operators  (AVOs). 

To  compare  the  requirements  of  current  DoN  acquisition  programs  with  the 
project  scope,  a  detailed  survey  of  the  Broad  Area  Maritime  Surveillance  (BAMS)  UAS, 
Vertical  Take-off  and  Land  Tactical  UAV  (VTUAV,  known  as  Fire  Scout),  and  Small 
Tactical  Unmanned  Air  System  (STUAS)  requirements  documents  was  performed.  The 
Key  Performance  Parameters  and  Key  System  Attributes  of  each  system  were  compared 
and  contrasted.  The  resulting  analysis  produced  a  list  of  twelve  requirements  necessary 
for  the  creation  of  a  common  functional  GCS  architecture  that  supports  AVO  functions. 

The  list  of  requirements  led  to  the  creation  of  a  proposed  common  GCS 
architecture.  The  Model  Based  Systems  Engineering  program  CORE®  was  used  to  show 
the  architectural  concept  through  the  Integration  Definition  for  Eunctional  Modeling 
(IDEEO)  language.  Each  sub-function  was  then  modeled  in  IDEEO  to  ensure  consistent 
data  flow  between  levels.  A  high  level  benefits  analysis  was  performed  assuming  the 
implementation  of  the  proposed  common  GCS  architecture.  This  analysis  was  limited  to 
the  AVO  functions  required  for  Basic  UAS  Qualifications.  It  showed  a  potential  cost 
savings  of  over  $400  million  in  O&S  for  training  aspects  of  the  GCS  common 
architecture  over  a  twenty  year  span.  This  quantification  did  not  include  potential 
benefits  other  than  those  found  in  training,  and  additional  benefits  can  be  expected  when 
other  logistical  elements  are  analyzed. 

Utilizing  a  common  GCS  architecture  would  enable  benefits  in  the  areas  of 
basing,  manpower  requirements,  personnel  assignments,  reliability,  maintainability, 
interoperability  and  training.  This  project  quantified  AVO  training  cost  benefits  and 
found  that  implementation  of  the  common  GCS  architecture  in  accordance  with  the 
derived  requirements  will  benefit  the  Department  of  Defense  through  reduced  O&S  costs 
and  increased  operational  capability. 
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I.  INTRODUCTION  AND  BACKGROUND 


Unmanned  Aircraft  Systems  (UASs)  have  become  an  integral  part  of  the  United 
States  armed  forces  as  well  as  other  militaries  around  the  world.  “When  the  U.S.  forces 
went  into  Iraq  in  2003,  the  military  had  fewer  than  170  unmanned  aerial  systems...  By 
2008,  the  number  of  unmanned  aerial  systems  had  reached  6,358”  [Firebaugh,  2009].  In 
the  U.S.  inventory,  the  acquisition  process  of  buying  complete  systems  in  a  single 
program  from  a  single  prime  contractor  has  led  to  a  Ground  Control  Station  (GCS)  being 
purchased  with  each  type  of  new  Unmanned  Air  Vehicle  (UAV).  The  proliferation  of 
UASs,  including  each  unique  GCS,  has  resulted  in  a  procurement  and  development 
process  that  has  not  had  a  chance  to  generate,  accept,  and  mandate  common  standards. 

This  proliferation  has  led  to  a  lack  of  commonality  and  interoperability  among 
UASs.  Mr.  John  Young,  a  former  Under  Secretary  of  Defense  for  Acquisition, 
Technology,  and  Logistics  (USD(AT&L)),  stated  in  a  2009  Acquisition  Decision 
Memorandum  (ADM)  that  commonality  in  UAS  GCSs  could  reduce  Department  of 
Defense  (DoD)  manpower,  procurement,  sustainment,  and  logistics  costs,  and  that 
interoperability  could  improve  joint  and  combined  operations.  He  went  on  to  state  his 
thoughts  on  the  importance  by  saying  “...the  acquisition  team  has  the  opportunity  to  do 
something  truly  joint  and  powerful  by  adopting  a  common  GCS  architecture  that  is  open 
and  thus  will  allow  for  rapid  addition  of  modular  functionality”  [USD(AT&L),  2009]. 

To  prove  his  point,  Mr.  Young  stated  that  if  certain  provisions  in  the  ADM  were 
not  addressed,  he  “...may  restrict  funding  obligations  on  the  UAS  GCS  development 
and/or  procurement  contract. . .”  [USD(AT&L),  2009].  This  statement  has  not  been  taken 
lightly  by  the  acquisition  community  and  reveals  the  immediacy  of  the  action  required  for 
investigation  of  the  problem  at  hand. 
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A. 


COMPONENTS  OF  A  UAS 


A  UAS  consists  of  one  or  more  UAVs  and  a  GCS.  A  GCS  is  the  interfaee  and 
conduit  between  human  users,  or  operators,  and  the  UAVs.  The  GCS  also  reeeives  and 
disseminates  information  to  outside  elements  including  military  commands  and  air  traffic 
control.  A  GCS  is  not  limited  to  the  ground,  but  can  also  be  onboard  a  ship,  vehicle, 
submarine,  or  airborne  platform.  For  the  purposes  of  this  report,  GCS  will  be  used  as  the 
generic  term  referring  to  the  control  element  of  the  UAV.  Figure  1  shows  an  example 
from  a  UAS  airspace  integration  brief  that  highlights  the  complex  eonneetions  between 
the  UAVs,  GCSs  and  other  entities  within  the  UAS  environment.  It  can  be  seen  in  this 
figure  that  the  GCS  is  the  central  element  for  interactions  between  the  operators,  UAVs, 
other  aircraft,  ground  support  elements,  air  traffic  control  and  command  authorities. 
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Figure  1.  Example  Detailing  UAV  and  GCS  Connections 


This  diagram  shows  an  example  of  the  connections  between  a  UAV,  a  GCS  and  other  entities  within  the 
UAS  environment.  Methods  of  communication  and  types  of  GCSs  will  vary  based  on  type  and  capability  of 

the  UAS.  Figure  after  [PMA-262,  2009]. 
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All  user  controlled  functions  of  the  UAV  are  input  through  the  GCS.  This 
includes  piloting  functions,  navigation,  sensor  payload  control,  and  in  some  cases 
weapons  control.  Most  large  UASs  are  staffed  by  two  or  more  personnel,  with  at  least 
one  being  an  Air  Vehicle  Operator  (AVO)  and  other  positions  being  a  Mission  Payload 
Operator  (MPO),  other  sensor  operators,  communications  operator,  etc.  The  key 
purposes  of  the  GCSs  are  to  function  as  the  interface  for  human  operators  to  control  or 
direct  the  UAV,  control  the  payloads  (both  sensors  and  weapons),  and  direct  information 
from  the  UAS  to  the  appropriate  command  authority. 

The  emphasis  has  been  on  the  air  vehicle  component  of  the  UAS,  however  a 
primary  driver  in  realizing  system  capabilities  is  the  GCS.  The  GCS  houses  the  most 
vital  interface  found  on  a  UAS,  the  connection  between  the  human  operator  and  the  air 
vehicle.  A  UAV  is  different  from  a  missile  due  to  a  high  level  of  interaction  between  the 
operator  and  the  air  vehicle,  allowing  real  time  mission  flexibility  and  tasking.  Through 
the  GCS  interface,  the  operator  (or  team  of  operators),  command  desired  air  vehicle 
functionality  including  takeoff  and  landing,  navigation,  sensor  operation,  and  weapons 
delivery.  The  GCS  may  also  serve  as  the  intelligence  center,  where  raw,  actionable  data 
is  analyzed,  mensurated,  and  relayed  to  other  combat  assets.  Legacy  GCS  development 
and  deployment  has  been  conducted  in  a  proprietary  manner,  which  has  lead  to 
stovepiped  systems  that  are  not  common  or  interoperable  across  different  UASs  [National 
Defense  Industrial  Association  (NDIA),  2003].  A  need  for  a  change  for  future  systems 
was  recognized  by  the  recent  ADM  dictating  that  the  DoD  services  develop  and 
implement  plans  to  increase  synergies  across  current  and  future  systems  [USD(AT&L), 
2009]. 


The  GCS  is  responsible  for  several  functions  contained  within  the  UAS 
architecture.  The  first  function  is  to  allow  the  AVO  to  control  and  monitor  the  UAV. 
The  AVO  commands  air  vehicle  navigation  and  maneuver  parameters  through  the  GCS. 
Different  human  interfaces  are  employed  by  current  GCSs  to  accomplish  this  task, 
including  the  use  of  stick-and-rudder  type  designs,  as  well  as  point-and-click  computer 
based  designs.  The  second  aspect  of  this  function  is  to  monitor  the  health  and  equipment 
status  of  the  UAV.  The  GCS  houses  the  displays  that  allow  the  AVO  to  detect 
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malfunctions  and  enact  corrective  measures  when  necessary.  The  monitoring  funetion  of 
onboard  UAV  sensors  also  allows  the  AVO  to  determine  whieh  sensors  are  operational, 
thus  driving  the  tacties  employed  in  conducting  the  UAS  mission. 

The  eontrol  and  operation  of  the  UAV  sensors  and  weapons  is  another  vital 
function  of  the  GCS,  as  they  provide  the  true  warfighting  eapability.  Different  UASs 
employ  different  sensors  with  different  eapabilities.  Eaeh  GCS  must  be  able  to  operate 
its  eorresponding  sensors  and  provide  information  to  the  sensor  operator  and  other 
crewmembers.  Currently  there  are  many  different  sensor  operator  interfaces  to  mateh  the 
number  of  different  sensors  employed  by  UASs.  These  sensors  usually  provide  the 
targeting  data  required  to  employ  the  various  weapons  carried  by  different  UAVs.  The 
man- in-the- loop  aspeet  required  to  launch  weapons  is  a  critieal  GCS  interfaee.  The 
ability  for  the  mission  eommander  to  eonduet  hostile  engagements  is  direetly  related  to 
the  quality  of  the  information  the  GCS  ean  display. 

These  operations  require  a  robust  method  of  communieation  between  the  GCS 
and  UAV.  This  is  a  vital  interfaee,  and  ean  vary  based  on  the  size  and  mission  of  the 
UAS.  The  two  basic  categories  of  air  vehicle  control  links  are  Line-Of-Sight  (LOS), 
whieh  is  generally  employed  on  smaller  UAVs,  and  Over-The-Horizon  (OTH),  which  is 
employed  on  larger  UAVs.  These  can  be  implemented  in  various  ways  and  several 
different  data  links  are  currently  used.  OTH  data  links  are  usually  done  via  a  satellite 
data  link.  This  ean  present  problems  due  to  the  limited  bandwidth  available,  especially  in 
some  eases  where  military  traffic  is  carried  by  commereial  satellite  systems  with  no 
overriding  priority.  With  the  growing  number  of  large  OTH  UASs,  the  available  satellite 
bandwidth  is  another  consideration  that  the  GCS  must  aeeommodate.  These  links,  along 
with  the  UAS  operator  funetions  are  shown  in  Figure  2. 
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Figure  2.  Links  Between  the  GCS  and  UAV  with  Operator  Functions 

This  figure  shows  the  communication  links  between  the  GCS  and  the  UAV.  Additionally,  the  roles  of  the 
UAS  operators  are  shown  in  the  GCS  portion  of  the  figure.  The  Human-Machine  Interface  (HMI)  is  used 
by  the  operators  to  enter  commands  to  the  UAV  through  the  GCS.  Figure  after  [IHS  (Global)  Limited, 

2009]. 


A  final  important  area  of  GCS  architecture  is  the  contingency  planning  and 
monitoring  of  the  UAS.  While  the  UAV  is  responsible  for  executing  pre-planned 
contingency  measures,  the  GCS  provides  the  means  to  program  them  into  the  UAV  flight 
control  logic.  Three  of  the  general  contingency  plans  that  need  to  be  accounted  for,  and 
pre-programmed  are: 

•  What  should  the  UAV  do  if  the  air  vehicle  control  data  link  should  fail  and  the 
UAV  can  no  longer  receive  commands  Ifom  the  ground? 

•  What  should  the  UAV  do  in  the  event  of  a  loss  of  the  engine  (especially  if  the 
data  link  has  been  lost)? 
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•  What  should  the  UAV  do  in  the  ease  of  extreme  emergeney  (engine  fire,  ete, 
espeeially  if  the  data  link  has  been  previously  lost)? 

There  may  be  alternate  methods  of  performing  these  eontingeney  funetions  in  future  UAS 
designs,  however,  eontingeney  planning  is  eurrently  eonsidered  a  vital  funetion  of  a  GCS. 

B.  COMMONALITY  AND  INTEROPERABILITY 

While  the  eoneepts  of  eommonality  and  interoperability  are  generally  understood, 
exaet  definitions  are  more  difficult  to  articulate.  Commonality  is  often  described  at  a 
high  level  as  the  ability  to  use  the  same  hardware,  software  or  data  links.  The  ability  to 
communicate  between  different  types  of  UASs  is  described  as  interoperability,  but  it  is 
often  associated  with  commonality.  Properly  defining  commonality  and  interoperability 
is  a  challenging  issue  among  many  DoD  UAS  user  groups.  The  primary  focus  of  this 
project  is  defining  commonality  with  the  realization  that  commonality  tends  to  enable 
interoperability. 

The  current  generation  of  UASs  has  been  in  development  for  defense  applications 
since  the  1980s  [Government  Accountability  Office  (GAO),  2006].  Commonality  among 
subsystems,  payloads,  and  ground  control  stations  have  not  yet  been  attained  [GAO, 
2009].  This  lack  of  commonality  is  seen  not  only  between  cross-service  UASs,  but  also 
within  Department  of  the  Navy  (DoN)  acquired  UASs.  All  DoN  UASs  are  currently 
developed  with  unique  dedicated  GCSs. 

The  current  DoD  acquisition  process  leads  to  a  lack  of  commonality  because  each 
UAV  system  is  procured  as  if  it  were  a  single  aircraft.  This  condition  is  referred  to  as 
stovepiping  as  it  results  from  a  lack  of  coordination  between  program  offices  on  issues 
such  as  commonality.  Therefore,  each  system  component,  both  UAV  and  paired  GCS  are 
developed  together  as  standalone  systems.  “In  an  effort  to  minimize  ‘stovepiping,’ 
Congress  has  mandated  that  all  unmanned  aircraft  weighing  more  than  45  pounds  must 
transition  to  a  tactical  common  datalink  that  will  enable  them  to  inter-operate  with 
various  ground  technologies”  [Jean,  2009]. 
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Another  barrier  to  obtaining  DoD  commonality  is  that  “manufacturers  have  been 
reluctant  to  share  their  proprietary  communications  datalink  formats  with  other 
companies.  They  produce  ground  stations  that  control  only  their  specific  aircraft,  which 
means  that  the  services  often  have  to  buy  the  complete  package  of  Air  Vehicle  (AV)  and 
GCS.  That  has  proven  cumbersome  and  inefficient  because  the  equipment  is  not 
compatible  with  aircraft  made  by  other  manufacturers”  [Jean,  2009].  Raytheon,  a 
company  that  makes  independent  GCSs,  stated  “we,  the  ground  system  providers,  are 
being  held  hostage  by  the  platform  providers”  [Jean,  2009].  Therefore,  as  more  systems 
are  being  acquired  by  the  DoN,  the  population  and  variety  of  GCS  equipment  has  begun 
to  proliferate  with  few  effective  efforts  to  increase  commonality  in  hardware,  software,  or 
logistics.  Additionally,  GCSs  have  proven  not  to  be  interoperable,  resulting  in  reduced 
operational  effectiveness.  A  detailed  discussion  about  commonality  and  interoperability 
can  be  found  in  Chapter  III.B. 

C.  EXAMPLE  COMMONALITY  PROBLEM:  PREDATOR  AND  SKY 

WARRIOR 

In  2001,  the  U.S.  Army  began  to  develop  requirements  to  replace  the  legacy  RQ-5 
Hunter  UAS.  The  U.S.  Army  was  having  problems  accessing  and  tasking  the  small 
number  of  UASs  in  the  DoD  inventory,  specifically  the  U.S.  Air  Force  (USAF)  Predator 
systems.  Due  to  the  lack  of  access  to  USAF  Predators,  the  U.S.  Army  decided  to  begin 
its  own  program  citing  ground  commanders’  “urgent  need  for  this  capability”  [GAO, 
2009].  The  U.S.  Army  put  out  their  own  request  for  proposal,  conducted  their  own 
source  selection  and  chose  the  MQ-IC  Sky  Warrior.  The  requirements  for  the  new  U.S. 
Army  UAV  program  appeared  to  be  very  similar  to  the  already  existing  Predator.  As 
stated  in  a  2009  GAO  report,  “Both  the  Air  Force  and  the  Joint  Staff  responsible  for 
reviewing  Sky  Warrior’s  requirements  and  acquisition  documentation  raised  concerns 
about  duplicating  existing  capability  -  specifically,  capability  provided  by  Predator.” 

The  U.S.  Army  could  have  purchased  Predators  or  helped  in  the  development  of 
the  follow-on  Predator-B  (Reaper),  but  instead  used  the  urgent  need  to  push  their  own 
uncommon  system  through.  This  decision  was  made  to  ensure  their  service-specific 
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requirements  were  not  affeeted  by  the  USAF  if  a  joint  solution  was  pursued.  General 
Atomies  won  the  U.S.  Army  souree  seleetion  and  bid  a  larger  (and  unique)  variant  of  its 
USAF  Predator.  The  U.S.  Army  developed  this  system  as  the  Sky  Warrior  instead  of 
joining  a  Reaper  or  Predator  development  [GAO,  2009]. 

It  is  important  to  note  that  the  GCS  for  the  USAF  Predator  is  not  eornmon  or 
interoperable  with  the  U.S.  Army  Sky  Warrior.  “The  ground  eontrol  station  the  Army  is 
developing  for  Sky  Warrior  is  expected  to  be  used  to  control  other  Army  unmanned 
aircraft,  it  will  not  be  common  with  the  Predator  and  Reaper  ground  control  station  used 
by  the  Air  Force”  [GAO,  2009].  While  the  U.S.  Army  is  trying  to  be  common  with  U.S. 
Army  GCSs,  these  nearly  identical  systems  cannot  communicate  or  control  each  other. 
The  GCS  for  the  U.S.  Army  adds  an  automatic  takeoff  and  landing  capability  missing  on 
the  Predator  GCS,  making  it  considerably  different  from  its  USAF  counterpart. 

This  example  shows  the  complexity  and  difficulty  in  accomplishing  common 
UAS  solutions  even  when  missions  and  requirements  are  similar.  Individual  services 
within  the  DoD  are  rarely  willing  to  compromise  on  service-specific  needs,  even  when 
confronted  with  the  expense  of  an  entirely  unique  acquisition  program. 

D.  RESEARCH  QUESTIONS 

The  implication  of  a  common  UAS  ground  control  station  leads  to  some 
interesting  research  questions.  The  following  five  research  questions  guided  the  direction 
of  this  project’s  research  and  analysis: 

Research  Question  1.  What  is  meant  by  common  and  what  is  this  project’s 

interpretation  of  common? 

Research  Question  2.  Is  there  a  link  between  commonality  and  interoperability! 

Research  Question  3.  Is  it  possible  to  achieve  some  level  of  commonality  for 

UAS  GCSs,  and  if  so,  what  requirements  are  necessary? 

Research  Question  4.  To  meet  these  requirements,  what  architectural 

characteristics  need  to  be  developed? 

Research  Question  5.  What  are  some  of  the  benefits  and  challenges  of  achieving 

UAS  GCS  commonality? 


8 


E.  PROJECT  GOALS  AND  DELIVERABLES 


The  primary  goal  of  this  project  was  to  investigate  the  challenging  aspects  of 
creating  common  UAS  GCSs  and  the  potential  benefits  of  achieving  this  commonality. 
Efforts  leading  to  this  goal  included  conducting  a  detailed  survey  of  available  background 
information  related  to  UASs  and  GCSs.  Commonality  and  interoperability  concerns  with 
respect  to  these  GCSs  have  been  explored. 

After  adequate  background  information  was  compiled,  high  level  requirements  for 
a  common  GCS  were  developed  based  on  multiple  sources.  These  sources  ranged  from 
existing  requirements  from  current  DoN  programs,  other  governmental  documents,  and 
concept  of  operations  from  UAS  communities.  The  final  list  of  extracted  requirements 
included  twelve  detailed  elements  that  would  ensure  the  capability  to  enable  common 
AVO  training  and  would  allow  for  GCS  interoperability  between  platforms. 

These  requirements  were  utilized  to  create  a  functional  architecture.  The 
functional  architecture  was  taken  to  a  fifth  level  of  decomposition  in  some  cases,  to 
ensure  adequate  detail  for  proper  implementation.  The  final  deliverable  includes  a 
hyperlinked  architecture  that  allows  for  point-and-click  decomposition  of  hierarchical 
levels. 


After  the  functional  architecture  was  developed,  a  small  subset  of  possible 
benefits  from  achieving  commonality  was  explored.  This  benefits  analysis  was  used  to 
show  some  of  the  quantifiable  advantages  that  the  DoN  could  gain  by  pursuing  the 
common  GCS  architecture. 

The  breadth  of  the  project  required  limiting  the  scope  of  the  efforts  in  order  to 
achieve  the  goals  in  the  time  allotted.  The  commonality  aspect  for  the  proposed  GCS 
architecture  was  limited  to  the  air  vehicle  control  operations  performed  by  the  AVO  only. 
Additionally,  the  architecture  was  limited  to  functional  vice  physical  allocations.  The 
benefits  that  could  be  expected  from  implementing  the  proposed  common  GCS 
architecture  were  limited  to  those  related  to  common  AVO  training  only.  This  effort  did 
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not  include  a  detailed  eost-benefit  analysis  due  to  limited  time  and  resourees.  Further 
details  regarding  the  seoping  of  the  projeet  ean  be  found  in  Chapter  IV. 


F.  SYSTEMS  ENGINEERING  PROCESS 

The  systems  engineering  method  utilized  for  this  project  was  a  tailored  approach 
to  the  process  presented  in  Systems  Engineering  Principles  and  Practice  [Kossiakoff  & 
Sweet,  2003].  This  method  deseribes  three  phases  of  systems  engineering  as  Concept 
Development,  Engineering  Development  and  Post  Development.  For  the  purposes  of  this 
project,  much  of  the  work  was  eontained  in  the  Coneept  Development  and  Engineering 
Development  phases.  Additional  doeumentation  of  the  tailored  systems  engineering 
proeess  ean  be  found  in  the  Projeet  Management  Plan  in  Appendix  A. 

The  generie  systems  engineering  proeess  was  then  tailored  speeifieally  for  use  in 
this  projeet.  The  tailored  process,  as  shown  in  Figure  3  on  the  next  page,  is  divided  into 
four  phases:  Information  Gathering  and  Problem  Definition,  Concept  Development, 
Engineering  Development,  and  Design  Recommendations  and  Conclusions. 

The  method  began  with  Information  Gathering  and  Problem  Definition.  Onee  the 
problem  had  been  defined,  the  iterative  phase  of  Concept  Development  was  initiated. 
This  iteration  eontinued  until  an  initial  funetional  arehiteeture  had  been  ereated  that 
satisfied  eritieal  functional  requirements.  Next,  the  Engineering  Development  iterated 
until  a  final  funetional  arehiteeture  had  been  developed  that  met  detailed  requirements 
based  on  stakeholder  feedbaek.  Easily,  the  Design  Recommendations  and  Conclusions 
were  produeed.  Problem  seoping  and  stakeholder  feedback  loops  were  utilized 
throughout  the  proeess  as  shown  in  Figure  3. 
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Figure  3.  Tailored  Systems  Engineering  Process  for  This  Project 

This  figure  is  the  tailored  systems  engineering  process  for  this  project.  The  process  is  divided  into  four  phases  of  Information  Gathering 
&  Problem  Definition,  Concept  Development,  Engineering  Development  and  Design  Recommendations  &  Conclusions. 
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1.  Information  Gathering  and  Problem  Definition 


The  first  phase  of  the  systems  engineering  process  included  defining  the  problem 
and  gathering  information.  The  problem  was  initially  presented  by  Naval  Air  Systems 
Command  (NAVAIR)  as  a  topic  of  interest  for  further  study.  In  addition  to  the  guidance 
Ifom  NAVAIR,  other  efforts  included  conducting  a  survey  of  available  documentation  to 
further  define  the  problem  related  to  GCS  commonality.  After  the  problem  was  properly 
defined,  existing  systems  were  researched  to  provide  an  adequate  background  for  further 
studies. 


After  information  gathering,  an  initial  scoping  of  the  problem  occurred.  This 
problem  scoping  was  iterative  with  the  concept  development  phase  to  ensure  the 
objectives  of  the  program  were  achieved  in  the  timelfame  allowed. 

2.  Concept  Development 

In  the  concept  development  phase,  the  team  performed  a  stakeholder  needs 
analysis  to  determine  the  requirements  and  priorities  of  the  stakeholders.  The  initial  step 
was  to  ensure  the  correct  set  of  stakeholders  had  been  identified.  The  team  then  elicited 
the  stakeholders’  requirements  and  priorities  potentially  affected  by  GCS  commonality. 
Requirements  and  constraints  were  defined  and  analyzed  in  relation  to  the  problem 
statement. 

An  initial  functional  analysis  of  legacy  GCS  architectures  was  performed  to 
identify  critical  functional  requirements  for  common  GCSs.  It  was  found  that  existing 
GCS  architectures  would  not  meet  all  of  the  requirements  for  a  common  GCS. 
Therefore,  a  new  common  GCS  functional  architecture  was  developed.  This  functional 
analysis  yielded  an  initial  functional  architecture  at  a  high,  conceptual  level. 

3.  Engineering  Development 

In  the  engineering  development  phase,  the  initial  functional  architecture  was 
further  developed  into  a  final  functional  architecture  for  a  common  GCS.  It  is  important 
to  note  that  the  functional  architecture  did  not  include  any  physical  allocation  for  the 
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common  GCS.  Additionally,  the  engineering  development  phase  performed  an  analysis 
of  potential  benefits  Ifom  achieving  this  eommon  GCS  architecture. 

4.  Design  Recommendations  and  Conclusions 

The  final  phase  in  the  defined  systems  engineering  process  utilized  the 
information  Ifom  the  preceding  phases  to  formulate  recommendations  on  the  future 
application  of  the  proposed  eommon  GCS  architecture  to  the  stakeholders. 

The  final  recommendation  for  U.S.  Navy  (USN)  aequisition  programs  was  to 
adopt  the  common  GCS  functional  architecture  provided  in  this  report  as  a  basis  for 
further  design.  Further,  the  benefits  in  training  afforded  by  this  arehitecture  ean  only  be 
realized  through  eonsolidation  of  training  infrastrueture  among  those  same  programs. 

G.  INTEGRATED  PRODUCT  TEAMS  AND  TEAM  MEMBER  ROLES 

To  facilitate  work  on  the  project,  the  Capstone  group  formed  a  team  named  the 
Joint  UAS  Common  Control  Station  (JUCCS).  A  logo  was  developed  as  part  of  the  team 
forming  process  and  can  be  seen  in  Appendix  B.  The  JUCCS  team  broke  into  Integrated 
Product  Teams  (IPTs)  to  perform  the  systems  engineering  process  that  was  defined  in 
previous  sections.  The  IPT  hierarehy  ean  be  seen  in  Figure  4.  The  roles  and 
responsibilities  of  the  individual  IPTs  are  defined  in  the  following  paragraphs. 


Figure  4.  JUCCS  Integrated  Product  Team  Hierarchy 

The  IPT  hierarchy  can  be  seen  in  this  figure.  The  PM  is  at  the  top  of  the  hierarchy  with  the  individual  IPTs 
reporting  upward  to  the  PM.  The  structure  includes  representatives  for  Project  Management, 
Requirements,  Architecture  and  Logistics. 
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The  Project  Manager  (PM)  was  responsible  for  managing  all  IPTs  within  the 
organizational  structure  of  the  Capstone  project.  The  PM  made  executive  decisions  at 
times  when  matters  were  not  agreed  upon  by  the  team  members.  The  PM  was  the 
primary  point  of  contact  between  the  project  advisors,  external  stakeholders,  and  the 
Capstone  team  members. 

The  Requirements  IPT  was  responsible  for  compiling  requirements  documents 
from  existing  DoN  UAS  programs  in  support  of  the  requirements  and  constraint  analysis. 
The  analysis  from  the  requirements  IPT  aided  with  the  architectural  development. 

The  Architecture  IPT  was  responsible  for  defining  and  implementing  the 
proposed  common  architecture.  Tasking  included  creation  of  an  upper  level  list  of 
requirements,  functional  decomposition  and  proposed  functional  architecture.  The 
architecture  team  members  used  the  CORE®  software  package  as  their  primary  tool. 

The  Logistics  IPT  was  responsible  for  assessing  potential  benefits  of 
implementing  the  common  architecture  designed  by  the  Architecture  IPT.  The 
assessment  included  benefits  that  could  be  expected  from  a  logistical,  primarily  training 
standpoint.  Tasking  included  development  of  appropriate  metrics  and  meetings  with 
stakeholders. 

The  Project  Management  IPT  was  responsible  for  assisting  the  PM  with  all 
project  management  efforts  including  schedule  generation  and  the  compilation  of 
document  deliverables.  The  Project  Management  IPT  included  editors,  configuration 
managers,  and  a  scheduler.  The  editors  were  responsible  for  the  proper  editing  of  all 
document  deliverables.  The  configuration  managers  were  responsible  for  configuration 
control  and  administration  of  the  learning  management  system  used  for  the  project.  The 
scheduler  was  responsible  for  maintaining  the  master  project  schedule. 
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II.  UAS  AND  GCS  BACKGROUND  INFORMATION 


This  section  provides  a  general  overview  of  GCSs,  their  components,  and 
respective  functions  based  on  a  limited  number  of  documents  that  are  directly  relevant  to 
the  discussion  of  commonality  and  interoperability  with  respect  to  UAS  GCSs.  The  most 
relevant  documents  reviewed  were  the  Office  of  the  Secretary  of  Defense  (OSD) 
Unmanned  Systems  Integrated  Roadmap  (2009),  GAO  commonality  and  interoperability 
reports  (March  2005;  December  2005;  2006;  2009),  STANAG  4586  (2007),  and  the 
ADM  from  USD(AT&L)  (2009).  These  documents  are  analyzed  and  referenced  in  this 
project.  There  are  other  documents  from  sources  such  as  American  Institute  of 
Aeronautics  and  Astronautics  (AIAA),  National  Aeronautics  and  Space  Administration 
(NASA)  along  with  documents  from  various  other  countries,  which  were  analyzed  for 
relevance,  but  are  not  cited  in  this  background  section.  Many  of  these  documents  are 
referenced  within  specific  sections  of  the  paper  as  appropriate. 

A.  UNMANNED  SYSTEMS  INTEGRATED  ROADMAP  (FY2009-2034) 

The  second  edition  of  the  FY2009-2034  Unmanned  Systems  Integrated  Roadmap 
[OSD,  2009]  provides  a  DoD-wide  vision  for  the  future  of  unmanned  systems.  It  lays  out 
the  potential  missions  that  unmanned  systems  could  perform  in  the  future,  describes  the 
functionality  and  performance  needed  to  execute  these  missions,  and  identifies  common 
areas  of  technology  maturation  that  can  lead  to  performance  improvements  for  all 
unmanned  systems:  UASs,  Unmanned  Ground  Vehicles  (UGVs),  and  Unmanned 
Maritime  Systems  (UMSs).  The  OSD  Roadmap  also  reflects  the  guidance  set  forth  in 
Section  141  of  the  John  Warner  National  Defense  Authorization  Act  for  FY2007  (Public 
Law  109-364)  to  address  joint  development  and  procurement  of  unmanned  systems  and 
components,  to  transition  service  unique  unmanned  systems  to  joint  systems,  to  evaluate 
the  organizational  structure  for  effective  management,  and  to  coordinate  and  budget  for 
the  development  and  procurement  of  unmanned  systems. 

As  reported  by  the  OSD  Roadmap,  the  technology  of  today  in  conjunction  with 
the  projected  advancements  of  the  future  will  enable  a  single  platform  to  perform 
multiple  missions  across  a  variety  of  mission  capability  areas.  For  example,  all  four 
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services  currently  employ  multiple  UASs  to  carry  out  a  variety  of  missions.  The  OSD 
Roadmap  asserts  that  the  DoD  has  an  opportunity  to  realize  a  greater  return  on 
investment  by  achieving  a  common  UAS  with  multi-mission  capabilities  rather  than 
investing  in  mission-unique  solutions.  It  recommends  that  the  DoD  “promote  the 
development,  adoption,  and  enforcement  of  Government,  international,  and  commercial 
standards  for  the  design,  manufacturing,  testing,  and  safe  operation  of  unmanned 
systems.” 

The  OSD  Roadmap  also  contends  that  interoperability  will  help  the  DoD  achieve 
its  vision  by  enhancing  operational  synergy  during  mission  execution  and  by  simplifying 
logistical  elements.  Interoperability  among  unmanned  systems  enables  information 
sharing  that  facilitates  situational  awareness  of  ground  combatant  commanders. 
According  to  the  OSD  Roadmap,  interoperability  can  be  achieved  through  the  acquisition 
of  common  components,  systems,  and  software,  or  by  building  systems  to  common 
interoperability  standards. 

While  the  OSD  Roadmap  proposes  that  the  DoD  strive  for  commonality  and 
interoperability,  it  provides  no  specific  direction  on  how  to  achieve  them.  It  recommends 
common  standards  but  does  not  provide  one.  The  OSD  Roadmap  itself  states  that  it  does 
not  “create  operational  concepts,  identify  requirements,  or  program  funds  to  invest  in 
technology  development  and  system  acquisition.  .  .  [and  it]  does  not  supersede  the  need 
for  the  Department  to  conduct  the  analysis  and  decision  making  associated  with 
identifying  the  best  means  to  satisfy  capability  gaps”  [OSD,  2009].  In  essence,  the  OSD 
Roadmap  directs  the  DoD  to  be  common  and  interoperable  but  it  does  not  provide  the 
tools  necessary  to  achieve  these  goals. 

B.  GOVERNMENT  ACCOUNTABILITY  OFFICE  REPORTS  06-49,  06-6I0T 

AND  09-520  ON  UNMANNED  AIRCRAFT  SYSTEMS 

The  Government  Accountability  Office  (GAO),  which  is  charged  with  auditing 
the  Government  and  its  activities,  has  been  investigating  the  status  of  unmanned  systems 
since  early  1988  [GAO,  December  2005].  Within  the  last  decade,  the  GAO  has  released 
reports  and  testimony  to  Congress  addressing  commonality,  interoperability,  operational 
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performance,  and  the  DoD’s  acquisition  management  approach  to  the  growing  demand 
for  UASs.  While  the  DoD  has  experienced  operational  success  with  UASs,  it  is  still 
challenged  with  maximizing  its  acquisition  resources  and  effectively  integrating  these 
assets  into  joint  combat  operations. 

With  the  DoD’s  plans  to  invest  more  than  $16  billion  from  2008  through  2013  to 
develop  and  procure  additional  UASs,  the  acquisition  of  such  systems  has  come  under 
scrutiny.  For  the  ten  unmanned  aircraft  acquisition  programs  that  GAO  reviewed  in 
2009,  total  development  costs  have  surpassed  initial  estimates  by  over  $3  billion,  or  37 
percent  [GAO,  2009].  Such  over-runs  put  strain  on  acquisition  resources,  which  can  lead 
to  performance  tradeoffs. 

The  DoD  recognizes  the  need  for  greater  commonality  among  UASs  in  order  to 
more  effectively  leverage  its  acquisition  resources.  The  National  Defense  Authorization 
Act  for  fiscal  year  2009  identifies  commonality  objectives  that  Congress  expects 
unmanned  system  policy  and  acquisition  strategy  to  achieve.  Those  objectives  include: 
the  procurement  of  common  payloads  by  vehicle  class,  achieving  commonality  of  ground 
system  architecture,  common  management  of  vehicle  and  payload  procurements,  ground 
station  interoperability  standardization,  and  common  standards  for  exchanging  data  and 
metadata  [GAO,  2009]. 

Although  UASs  have  seen  success  in  the  operational  environment,  their  effective 
integration  into  joint  combat  operations  remains  a  challenge  [GAO,  2006].  Not  all  UASs 
are  able  to  easily  exchange  data  with  other  communication  systems  because  they  were 
not  designed  to  interoperable  communications  standards  [GAO,  December  2005].  Joint 
operations  have  been  hampered  when  communication  systems  are  incompatible.  For 
example,  operating  forces  may  be  required  to  operate  their  own  UASs  to  accomplish  a 
mission,  rather  than  using  UASs  that  are  already  operating  in  the  same  area.  “To  permit 
the  sharing  of  tactical  intelligence  obtained  by  unmanned  aircraft  sensors,  the  Services  or 
combatant  commands  have  developed  certain  technical  patches  that  permit  compatibility 
but  slow  data  transmission”  [GAO,  2006].  Timely  dissemination  of  information  is 
critical  to  combat  operations  as  delays  in  the  receipt  of  the  information  can  undermine 
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U.S.  forces’  ability  to  attack  time-critical  targets  or  allow  the  targets  to  escape  [GAO, 
December  2005].  The  commander  of  U.S.  Central  Command  recently  testified  that 
experiences  to  date  highlight  the  importance  of  an  established  interoperability  standard 
for  all  intelligence  systems  that  can  function  in  a  joint  and  combined  environment  [GAO, 
2006]. 


Although  DoD  doctrine  requires  interoperability,  no  specific  standards  or  detailed 
instruction  exist,  and  no  organization  has  been  given  the  authority  to  enforce  program 
direction  [GAO,  2006].  The  DoD  specifies  that  systems,  units,  and  forces  shall  be  able  to 
provide  and  accept  data  and  information  to  and  from  other  systems  and  shall  effectively 
interoperate  with  other  U.S.  forces  [GAO,  December  2005].  It  does  not,  however, 
provide  guidance  on  how  this  is  to  be  accomplished.  The  National  Defense 
Authorization  Act  for  Fiscal  Year  2009  identifies  Congress’  objectives  for  UAS  policy 
and  acquisition  strategy.  The  Act,  however,  provides  no  guidance  or  direction  on  how  to 
achieve  the  desired  commonality,  or  how  to  measure  success. 

While  the  2002  version  of  the  Unmanned  Aerial  Vehicles  Roadmap  [OSD,  2002] 
emphasizes  the  need  for  UAS  interoperability  and  identifies  a  number  of  existing 
standards  for  which  systems  should  comply,  it  indicates  that  detailed  standards  for 
interoperability  have  not  yet  been  developed  [GAO,  December  2005].  This  situation  still 
exists  today  with  current  systems.  GAO  has  reported  that  the  OSD  Roadmap  describes 
desired  capabilities  for  UASs  such  as  commonality,  integration,  and  interoperability,  but 
crucial  elements  of  how  to  develop  and  implement  a  strategic  plan  are  lacking.  It  does 
not  provide  specific  guidance  on  UAS  development,  such  as  a  clear  link  among  the  goals, 
desired  capabilities,  and  plans.  Additionally  the  OSD  Roadmap  does  not  provide  specific 
guidance  on  related  force  structure  integration  to  sufficiently  address  the  interrelationship 
among  service  plans  to  each  other  and  how  they  promote  joint  operations,  opportunities 
for  joint  endeavors,  investment  priorities  and  related  funding  needs  [GAO,  2006]. 

The  USD(AT&L)  created  the  Joint  UAV  Planning  Task  Force  in  October  2001. 
The  Task  Force  is  the  DoD’s  focal  point  for  helping  establish  interoperability  standards. 
Although  the  Task  Force  aims  to  guide  UAS  acquisition,  planning,  prioritization,  and 
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execution  across  services,  it  does  not  have  sufficient  authority  to  enforce  program 
direction  [GAO,  March  2005]. 

The  development  and  implementation  of  appropriate  interoperability  standards 
will  help  achieve  successful  integration  and  interoperability  of  UASs,  but  until  the  DoD 
addresses  development  of  non-interoperable  systems  and  enforces  common  standards 
among  the  services,  problems  are  likely  to  continue  and  possibly  become  more 
widespread  as  new  UASs  are  developed  and  fielded.  GAO  has  made  recommendations 
to  the  Secretary  of  Defense  to  develop  standards  for  communications  interoperability  and 
overall  UAS  interoperability  and  to  establish  an  office  with  sufficient  authority  to  enforce 
program  direction  [GAO,  2006].  GAO  has  also  recommended  that  DoD  establish  a  plan 
that  clearly  identifies  “goals,  requirements,  programs,  funding  needs,  performance 
measures,  and  the  interrelationship  of  service-specific  programs  to  each  other”  [GAO, 
March  2005]. 

C.  STANAG  4586:  STANDARD  INTERFACES  OF  UAV  CONTROL  SYSTEM 

FOR  NATO  UAV  INTEROPERABILITY 

North  Atlantic  Treaty  Organization  (NATO)  Standard  Agreement  (STANAG) 
4586  was  created  when  the  UAS  acquisition  community  realized  a  shortage  of  standards 
applicable  to  their  unique  system  development  requirements  [NATO,  2007].  While  there 
has  been  generous  re-use  of  existing  commercial  and  military  standards  produced  through 
other  system  developments,  there  is  a  shortage  of  unique  and  specific  standards  for  the 
UAS  community.  As  mentioned  earlier,  the  UAS  development  created  stovepiped 
designs  and  although  this  was  fairly  acceptable  when  the  community  was  smaller,  the 
recent  rapid  growth  in  the  quantity  of  systems  presently  fielded  has  created  an 
interoperability  problem  that  this  document  was  initiated  to  discuss. 

In  the  DoD,  recent  efforts  within  the  services  have  been  applied  to  acquiring 
unmanned  systems  with  increased  commonality.  One  effort  in  particular  has  each  service 
providing  representation  in  a  collaborative  effort  through  participation  in  Office  of  the 
Under  Secretary  of  Defense  sponsored  Standards  and  Interoperability  Integrated  Product 
Team  (S&I  IPT).  “The  S&I  IPT  is  chartered  to  provide  recommendations  for 
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regulations,  policies,  and  standards  that  will  lead  to  eventual  acceptance  of  unmanned 
military  aircraft  routinely  flying  among  civilian,  manned  aircraft”  [OSD,  2009]. 
STANAG  4586  is  one  of  the  standards  that  this  IPX  is  helping  to  generate  and  define,  as 
there  is  interest  within  the  DoD  to  be  common  with  NATO  organizations.  Meanwhile, 
the  international  community  through  the  NATO  Standardization  Agency  has  been 
investigating  the  issue  of  multi-national  interoperable  systems.  “In  1998,  a  NATO 
Specialist  Team  began  work  on  a  standard  conceived  to  standardize  unmanned  control 
systems  interfaces  to  help  enable  UAS  interoperability”  [CDL  Systems,  2009].  It  was 
their  works  which  lead  to  the  creation  of  STANAG  4586  and  which  the  S&I  IPX  is 
playing  an  active  role. 

There  are  four  primary  items  of  interest  which  STANAG  4586  helps  to  define. 
One  of  the  first  items  is  a  standard  top-level  UAS  architecture,  which  is  depicted  in 
Figure  5.  The  UAS  architecture  is  composed  of  four  main  elements:  the  air  vehicle 
element,  the  payload  element,  the  data  link  element  and  the  UAV  surface  element,  or 
more  commonly  referred  to  as  ground  station  element.  It  establishes  the  air  vehicle  as  an 
entity  upon  itself  The  payload  includes  any  of  the  equipment  onboard  meant  to  support 
the  mission  and  not  directly  used  for  flight  of  the  aircraft.  It  could  be  any  form  of 
camera,  radar  or  any  available  equipment,  which  is  to  be  flown  on  the  vehicle.  The  data 
link  element  is  the  form  of  communication  between  the  air  vehicle  and  the  ground 
element,  most  likely  some  type  of  Radio  Frequency  (RF)  transmission.  The  ground 
station  element  is  the  set  of  equipment  on  the  ground  that  controls  the  air  vehicle  and  the 
payload  systems  onboard.  Agreement  on  fundamental  system  architecture  lays  the 
foundation  for  more  detailed  definitions  associated  with  interfaces  and  UAS  elements. 
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Figure  5.  Top-Level  UAS  Architecture  as  Defined  by  STANAG  4586 


This  diagram  partitions  the  UAS  into  defined  elements  and  shows  the  primary  interfaces.  Figure  from 

[NATO,  2007]. 


The  second  item  of  interest  that  STANAG  4586  addresses  is  the  definition  of 
Levels  of  Interoperability  (LOIs).  The  LOIs  are  shown  in  Table  1.  The  intent  for  the 
creation  of  the  LOIs  was  to  assist  in  the  understanding  of  various  functional  capabilities, 
which  are  supported  by  the  interfaces.  LOI  1  is  a  condition  in  which  information 
originating  from  a  UAV  is  passed  to  a  third  party  via  the  GCS.  LOI  2  is  a  condition 
whereby  the  controlling  asset  is  directly  receiving  data  from  the  UAV.  LOI  3  is  a 
condition  where  an  asset  receives  strictly  payload  data  and  it  is  received  straight  from  the 
UAV.  LOI  4  is  a  condition  where  an  asset  is  able  to  control  just  the  UAV  platform  and 
not  the  payload  systems.  The  control  available  to  that  asset  does  not  include  the  ability  to 
manage  the  UAV  takeoff  or  landing.  Finally,  LOI  5  is  a  condition  where  an  asset  has 
control  of  the  UAV  for  all  phases  of  flight  including  takeoff  and  landing.  It  does  not 
imply  control  of  payload  systems. 
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Table  1.  Levels  of  Interoperability 

This  table  shows  the  five  Levels  of  Interoperability  (LOIs)  and  the  definitions  associated  with  each.  Table 

after  [NATO,  2007]. 


LOI  Level 

Definition 

1 

Indirect  receipt  of  UAV  data 

2 

Direct  receipt  of  UAV  data  where  direct  covers  reception  of  the  UAV 
data  by  the  GCS  when  it  has  direct  communication  with  the  UAV 

3 

Control  and  monitoring  of  the  UAV  payload  in  addition  to  direct 
receipt  of  UAV  data 

4 

Control  and  monitoring  of  the  UAV,  less  launch  and  recovery 

5 

Control  and  monitoring  of  the  UAV,  plus  launch  and  recovery 

Something  to  consider  is  that  an  asset  could  have  multiple  LOIs  at  any  given  time. 
For  example,  a  small  hand-held  UAV  with  a  camera  as  its  payload  could  utilize  a  GCS 
for  control  of  the  air  vehicle  for  launch  and  recovery,  control  of  the  air  vehicle  in  flight, 
and  receipt  of  camera  data.  This  encompasses  LOI  2,  4  and  5.  There  could  be  a  separate 
ground  element  used  to  monitor,  control  and  receive  the  payload  data,  which  would 
include  LOI  2  and  3.  Should  these  two  ground  elements  be  configured  as  a  single  item,  it 
would  have  LOI  2,  3,  4  and  5. 

The  third  item  that  STANAG  4586  helps  define  is  a  common  physical 
architecture  for  the  UAS  as  shown  in  Figure  6.  Note  that  the  language  used  by  the 
STANAG  calls  this  figure  a  functional  architecture,  but  it  is  understood  here  to  be  a 
physical  representation.  This  physical  architecture  takes  into  consideration  that  an  AV 
may  not  directly  interface  with  the  core  UAV  Control  System  (UCS)  but  instead  might 
require  some  translation  in  order  to  be  interoperable.  The  Vehicle  Specific  Module 
(VSM)  would  host  the  functionality  needed  to  translate  the  necessary  information  for  a 
specific  AV  if  necessary.  Similarly,  some  translation  may  be  required  with  the  interface 
to  the  Command,  Control,  Communication,  Computer  and  Intelligence  (C4I)  system.  In 
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that  case,  the  Command  and  Control  Interface  Specific  Module  (CCISM)  would  perform 
the  neeessary  translation. 


Figure  6.  UAS  Physical  Architecture  as  Defined  by  STANAG  4586 


This  diagram  depicts  the  control  station  physical  elements  and  interfaces  as  defined  by  STANAG  4586. 

Figure  from  [NATO,  2007]. 


The  fourth  and  final  item  of  interest  that  STANAG  4586  addresses  is  a  detailed 
definition  of  the  three  main  GCS  interfaces.  The  Data  Link  Interface  (DLI),  the 
Command  and  Control  Interface  (CCI)  and  the  Human  Computer  Interface  (HCI)  are 
each  detailed  in  separate  appendiees  of  the  STANAG.  The  STANAG  has  grown  in  detail 
with  each  successive  revision  and  update.  Presently,  the  DLI  and  CCI  are  well 
documented  in  Edition  2  with  the  HCI  in  a  lesser  state  of  eompletion.  It  is  expeeted  that 
the  HCI  will  be  updated  with  the  next  edition  as  well  as  eontinually  refined  and  clarified 
as  required  throughout  the  document. 

The  major  take  away  from  the  STANAG  is  documentation  of  a  common 
architecture  and  functional  description  of  a  UAS  at  a  very  high  level.  Additionally,  the 
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document  provides  a  detailed  explanation  of  the  major  GCS  interfaces.  Having  these 
items  quantified  and  established  in  a  solitary  standard  assists  the  UAS  community  by 
providing  a  single  Ifame  of  reference  and  baseline  to  assist  in  system  aequisition  and 
development  as  well  as  operational  usage. 

As  mueh  as  the  STANAG  has  tried  to  facilitate  interoperability  within  the  UAS 
eommunity,  there  are  areas  that  are  lacking  which  would  be  suitable  for  future  updates  or 
general  knowledge  when  reviewing.  First,  being  a  NATO  standard,  there  are  limits  to  its 
applicability  to  non-NATO  system  development  efforts.  The  U.S.  DoD  works  with 
forces  that  are  not  neeessarily  part  of  NATO.  True  interoperability  for  the  DoD  is  not 
just  within  itself  and  with  NATO  forees,  but  with  all  the  forces  that  may  come  into 
coalition  operations. 

Seeond,  while  the  STANAG  tries  to  itemize  eaeh  element  of  the  Data  Link 
Interfaee  (DLI)  and  classify  them  as  common  messages,  it  also  allows  for  private 
messages.  Private  messages  allow  for  support  of  unique  functionality.  As  industry 
develops  more  systems,  there  is  a  growing  trend  of  more  private  message  usage.  As  a 
result,  manufaetures  can  claim  adherence  to  an  open  standard  while  simultaneously 
having  signifieant  relianee  on  the  use  of  unique  private  messages. 

Finally,  another  growing  concern  with  usage  of  the  STANAG  is  the  evolving 
mandates  for  internet  protocol  based  networked  family  of  systems  by  the  DoD.  Whereas 
the  STANAG  looks  to  ensure  interoperability  by  locking  down  configurations  and  strict 
adherence  to  interfaee  definitions,  the  DoD  is  moving  towards  a  networked  and  more 
loosely  eoupled  family  of  systems  approaeh.  These  approaehes  eonfiict  with  one  another 
and  the  STANAG  has  not  evolved  to  address  this  situation.  In  closing,  while  the 
STANAG  has  done  a  good  job  at  fostering  a  method  to  aehieve  interoperability,  there  are 
areas  that  still  need  to  be  addressed  as  the  paee  of  system  development  outpaees  its 
ability  to  keep  up. 
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D.  USD(AT&L)  ADM  2009:  UNMANNED  AIRCRAFT  SYSTEMS  GROUND 

CONTROU  STATION  ACQUISITION  DECISION  MEMORANDUM 

On  11  February  2009,  the  USD(AT&L),  Mr.  John  Young,  issued  the  UAS  GCS 
Aequisition  Deeision  Memorandum  (ADM)  directing  the  Secretaries  of  the  Army,  Navy, 
and  Air  Force  to  develop  plans  to  incorporate  open  architectures  in  the  development  of 
UAS  GCSs.  The  direction  provided  in  the  memorandum  was  the  result  of  an  extensive 
program  review  of  USAF  and  U.S.  Army  UAS  GCS  acquisition  efforts.  Mr.  Young 
concluded  that  the  acquisition  community  “has  the  opportunity  to  do  something  truly 
joint  and  powerful  by  adopting  a  common  GCS  architecture  that  is  open  and  thus  will 
allow  for  rapid  addition  of  modular  functionality”  [USD(AT&L),  2009].  In  addition  to 
the  warfighting  flexibility  that  modular  functionality  allows,  several  other  benefits  of  a 
common,  open  GCS  architecture  are  discussed  to  include:  innovation,  competitive 
options,  increased  cost  control,  interoperability,  efficient  flow  of  data  between 
stakeholders,  reduced  theater  complications,  training  efficiencies,  increased  safety,  and 
improvements  in  reliability  and  maintainability.  All  of  these  benefits  have  a  direct 
correlation  to  reduced  Life  Cycle  Costs  (LCC)  in  the  development,  operation,  and 
sustainment  of  UASs. 

As  discussed  in  the  introduction,  UAS  GCS  development  to  date  has  been 
characterized  by  proprietary  systems  and  interfaces.  This  has  hindered  the  ability  of  the 
services  to  adapt  functionality  to  meet  emerging  requirements,  and  has  made  the 
interoperability  between  UASs  virtually  impossible.  Proprietary  development  has  also 
eliminated  the  possibility  of  introducing  the  benefits  of  competitive  acquisition  strategies 
to  upgrade  existing  systems,  which  ultimately  leads  to  higher  costs  to  the  government. 
The  common,  open  systems  architecture  directed  by  USD(AT&L)  is  a  complete  change 
from  these  past  practices.  Open  systems  architectures  that  address  all  of  the  necessary 
GCS  interfaces  would  allow  the  government  greater  flexibility  with  acquisition  strategies. 
These  open  interfaces  could  be  called  out  in  future  requirements  documents  allowing  for 
greater  interoperability  and  competition.  Open  systems  architectures  also  beget 
innovation,  as  any  corporation  or  government  activity  will  have  the  opportunity  to  bring 
unique  solutions  to  support  the  growth  and  sustainment  of  UASs. 
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Interoperability  is  a  key  focus  of  the  ADM.  Mr.  Young  points  out  that  reduced 
theater  complications  can  be  achieved  through  a  common  GCS  architecture.  The  ability 
to  control  tasking  and  receive  data  from  cross-service  UASs  dramatically  increases  the 
effectiveness  of  the  combatant  commanders  in  conducting  military  operations.  Currently, 
UASs  are  service  unique,  and  data  flow  between  differing  operational  nodes  takes 
excessive  time.  As  discussed,  interoperability  is  different  from  commonality,  and  Mr. 
Young  reinforces  this  concept  in  the  ADM.  The  ADM  does  not  direct  that  GCSs  across 
all  services  be  exactly  the  same  (common),  but  rather  the  “flexibility  to  adapt  the  man- 
machine  interface  for  specific  Military  Service’s  Concept  of  Operations”  [USD(AT&L), 
2009]  be  achieved  while  the  underlying  architectures  employ  common  components  to  the 
maximum  extent  possible.  This  allows  the  services  to  adapt  human-machine  interfaces 
that  maximize  performance  based  upon  different  operational  scenarios  while  maintaining 
a  common  architecture  and  computing  hardware.  The  common  architecture  and 
hardware  reduce  government  acquisition  costs  and  allow  cross  service  maintenance  and 
supply  chain  management  for  UASs. 

The  ADM  also  alludes  to  the  dismal  safety  record  of  current  UASs.  Open, 
common  GCS  architectures  will  allow  for  increased  training  efficiencies  for  UAS 
operators  and  maintainers,  and  may  improve  the  safety  record  described  by  the  ADM. 
Much  like  the  training  pipeline  for  the  Joint  Primary  Air  Training  System  (JPATS)  and 
Joint  Strike  Fighter  (JSF)  aircraft,  UAS  operators  and  maintainers  across  multiple 
services  could  receive  training  at  the  same  location.  This  enables  the  potential  for 
government  cost  savings  in  facilities  and  reduced  development  of  service  unique 
courseware.  It  also  allows  for  mission  flexibility,  as  there  is  the  potential  for  cross 
service  operation  of  UASs.  Finally,  it  will  increase  the  small  pool  of  qualified  UAS 
operators.  Mr.  Young  also  highlights  that  takeoff  and  landing  is  the  most  likely  regime 
for  a  UAS  mishap,  and  directs  the  services  to  consider  the  employment  of  autonomous 
control  to  reduce  this  occurrence.  The  ADM  specifically  tasks  the  USAF  to  incorporate 
this  capability  into  its  Predator  and  Reaper  inventory. 

To  accomplish  the  objectives  discussed,  the  service  secretaries,  in  coordination 
with  the  UAS  Task  Force,  are  directed  by  the  ADM  to  “initiate  a  joint  effort  to  develop 
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and  demonstrate  a  eommon,  open,  and  sealable  UAS  arehiteeture  supporting  Groups  2-5 
UAS”  [USD(AT&L),  2009].  Speeific  aetions  lromUSD(AT&L)  inelude: 


•  Aeeelerate  the  fielding  of  Common  Data  Link  (CDL)  eompliant 
oommunieation  systems 

•  Conduet  a  user  assessment  of  the  Sky  Warrior  One  System  GCS  to  evaluate 
aspeets  of  funetionality  that  eould  be  applied  to  other  GCSs 

•  Identify  the  lead  serviee  and  management  structure  toward  these  efforts 

•  Develop  a  plan  to  conduct  prototype  demonstration  with  Predator,  Reaper,  and 
Sky  Warrior  UAS  with  Broad  Area  Maritime  Surveillance  (BAMS)  and 
Global  Hawk 

•  Develop  competitive  acquisition  strategies  for  future  GCS  procurements 

Finally,  USD(AT&L)  highlights  the  importance  of  these  GCS  efforts  by  ordering  that  any 
current  UAS  programs  break  out  the  GCS  effort  as  a  subprogram  to  increase  oversight 
and  visibility. 

Since  the  release  of  the  ADM  the  services  have  begun  taking  steps  toward  completing 
these  tasks.  Industry  is  also  excited  to  participate  in  the  growing  UAS  market,  which  is 
projected  to  be  over  $62  billion  over  the  next  decade  [Shalal-Esa,  2009].  Mr.  Bigham, 
Director  of  Business  Development  for  Raytheon  Missile  Systems,  sees  the  ADM  as  a 
watershed  event.  “The  fact  that  he  forced  everyone  to  use  an  open  interface  control 
document  is  the  most  important  thing  to  happen  in  unmanned  systems”  [Warwick  & 
Chavanne,  2009].  It  is  also  recognized  by  USD(AT&L)  that  this  effort  will  take  several 
years.  Mr.  Weatherington,  the  Defense  Department  Deputy  Director  for  Unmanned 
Warfare  states,  “Effectively  transitioning  ifom  where  we  are  today  to  where  we  need  to 
be  in  the  future  will  take  time.  Our  strategy  is  to  develop  goals  for  the  future 
architecture,  then  migrate  legacy  systems  toward  that  architecture  as  they  evolve.  New 
systems  would  be  required  to  adopt  the  new,  common  architecture”  [Warwick  & 
Chavanne,  2009]. 

The  ADM  is  an  important  document  that  provides  direction  with  regards  to  the  need 
for  commonality  in  UAS  GCS  development.  This  document,  however,  is  not  without  its 
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shortcomings.  First,  the  assertions  in  the  doeument  related  to  benefits  that  eould  be 
expected  trom  achieving  GCS  commonality  are  in  no  way  substantiated.  These  potential 
benefits  are  based  on  conventional  notions  about  what  improvements  commonality  can 
provide.  Second,  the  extent  of,  and  method  for  executing  the  commonality  are  not 
deseribed.  The  ADM  provides  a  goal  without  any  specific  guidance  on  how  to  achieve 
the  goal. 

E.  VARIATIONS  OF  GROUND  CONTROL  STATIONS 

GCSs  can  vary  greatly  in  form  and  function.  These  differences  ean  generally  be 
tied  to  the  size,  mission,  and  eost  of  the  UAS.  Very  small  UASs,  sueh  as  those  produced 
by  AeroVironment,  can  be  controlled  by  a  small  device  similar  to  a  Personal  Data 
Assistant  (PDA)  as  shown  in  Figure  7.  The  slightly  larger  hand  launehed  RQ-1  IB  Raven 
ean  be  eontrolled  Ifom  a  laptop  sized  device  such  as  the  one  shown  in  Figure  8.  Control 
of  these  smaller  UASs  is  localized  and  many  times  can  only  be  eommanded  through 
pre-programmed  flight  profiles  or  LOS  communication.  In  contrast,  the  USAF  Global 
Hawk  is  controlled  Ifom  a  deployable  trailer,  where  there  may  be  multiple  operators 
manning  several  different  stations  as  seen  in  Figure  9.  These  larger  GCSs  are  eapable  of 
transmitting  commands  and  receiving  data  over  thousands  of  miles  away  via  satellite 
communications.  For  these  large  systems,  the  GCS  may  not  be  eo-loeated  with  the  actual 
airfield  that  houses  the  air  vehicle.  For  example,  some  large  GCSs  are  located  in  the 
United  States  while  the  UAV  is  flying  combat  missions  over  the  skies  of  Iraq  or 
Afghanistan.  In  these  cases  the  Launch  Recovery  Elements  (LREs)  are  stationed  at  the 
air  bases  where  the  UAV  takes-off  and  lands.  The  LRE  has  control  over  the  UAV  only 
during  terminal  control  during  launch  and  recovery,  while  the  GCS  conducts  the  transit 
and  taetical  portions  of  the  UAV  mission.  Again,  it  is  important  to  note  that  while  it  is 
called  a  ground  control  station,  the  control  element  itself  eould  be  onboard  a  ship, 
submarine,  or  manned  aircraft. 
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Figure  7.  Small  Handheld  AeroVironment  GCS 


Small  handheld  devices,  such  as  the  one  depicted  above,  can  serve  as  the  primary  air  vehicle  control 
function  for  small  UASs.  Usually  these  smaller  UASs  are  hand  launched,  and  have  an  autopilot  to  land, 
reducing  the  necessary  functionality  of  the  operator  interface.  Figure  from  [AeroVironment  Inc.,  2009]. 


Figure  8.  Small  UAS  Ground  Control  Station 

The  RQ-llB  Raven  can  be  controlled  from  a  highly  portable  system.  For  these  less  complex  UASs,  a 
single  operator  may  control  all  air  vehicle  functionality  such  as  takeoff,  executing  the  mission,  and  the 
recovery  of  the  UAS.  Figure  from  [Independant  Defence  Consultant,  2009]. 
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Figure  9.  Larger  UAS  Ground  Control  Station  for  Global  Hawk 

The  Global  Hawk  Ground  Control  Station  can  be  found  in  a  trailer  (as  depicted  above)  or  housed  in  a 
stationary  building.  There  are  several  operator  stations  to  execute  a  Global  Hawk  mission.  It  is  likely  that 
the  picture  above  is  during  the  transit  phase  of  the  mission,  as  the  sensor  operator  stations  are  not  manned. 

Figure  from  [Aviation  Week,  2009]. 

The  Predator  UAS  has  been  in  service  for  several  years,  and  its  GCS  provides  an 
example  of  the  interface  required  to  conduct  air  vehicle  control  tasks.  The  GCS  for  the 
Predator  is  shown  in  Figure  10.  The  Predator  has  a  two-crew,  side-by-side  layout  that 
allows  the  pilot  and  the  sensor  operator  to  share  situational  awareness  across  common 
screens.  In  this  picture,  the  pilot  is  on  the  left,  and  the  sensor  operator  is  on  the  right, 
which  is  the  standard  setup  for  Predator  and  Reaper  operations.  The  Predator  GCS  uses  a 
joystick  approach  for  UAV  and  sensor  control,  however  there  is  a  keyboard  and  trackball 
for  some  air  vehicle  control  functions.  The  GCS  also  houses  the  radio  contact  between 
the  Predator  operators  and  the  forward  tactical  air  controller.  These  communications  are 
accomplished  through  the  headsets  the  operators  are  wearing.  The  pilot  and  the  sensor 
operator  have  the  ability  to  talk  internally  to  each  other  and  also  to  the  air  vehicle  control 
element  that  is  responsible  for  tasking  airborne  assets. 
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Figure  10.  Predator  Ground  Control  Station 

Inside  a  Predator  ground  control  station  at  Creech  Air  Force  Base  showing  commercial  monitors  and  rack 
mounted  militarized  monitor.  Figure  from  [IHS  (Global)  Limited,  2009]. 

Figure  11  shows  Raytheon’s  concept  of  a  future  GCS  that  could  be  used  for 
Predator  and  other  UASs.  By  optimizing  the  GCS  layout  there  is  the  potential  to  reduce 
the  number  of  operators  that  are  required  for  each  UAS. 


Figure  11.  Raytheou’s  Universal  Control  Prototype  Ground  Control  Station 

Raytheon ’s  concept  for  a  GCS  could  be  applied  to  several  currently  fielded  and  future  UASs.  Figure  from 

[Defense  Update,  2009]. 
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The  Fire  Seout  is  an  unmanned  helieopter  that  is  currently  in  development.  The 
relative  size  of  the  Fire  Scout  is  similar  to  that  of  a  Predator  UAS.  As  such,  the  GCS, 
depicted  in  Figure  12,  is  founded  upon  the  same  design  as  the  Predator.  The  Fire  Scout 
GCS  employs  the  same  two-operator,  side-by-side  concept  that  is  currently  used  by  the 
Predator  system.  The  Fire  Scout  is  also  being  designed  to  have  more  autonomous 
operating  capability  than  the  Predator,  which  leads  to  a  more  streamlined  control  station 
design  when  compared  to  Predator.  There  is  the  possibility  that  as  the  system  matures, 
the  GCS  may  look  more  like  the  single  operator  Raytheon  design  as  shown  in  Figure  11. 


Figure  12.  Fire  Scout  GCS 


The  Fire  Scout  GCS  is  another  side-by-side  design  where  two  operators  control  the  air  vehicle.  Figure 

from  [Globe  Newswire  Inc.,  2009]. 


F.  SUMMARY  OF  BACKGROUND  INFORMATION 

The  OSD  Roadmap,  GAO,  and  USD(AT&L)  all  call  for  more  commonality 
between  both  inter-service  and  intra-service  GCS  designs.  This  desire  has  been  attributed 
to  a  need  for  more  interoperability,  greater  ability  to  share  tactical  information,  and  a 
perceived  reduction  in  LCC.  These  documents  surmise  that  such  goals  could  be  met  with 
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the  use  of  modular,  open  souree,  standardized  systems,  but  none  of  the  doeuments  offer 
any  specific  guidelines  on  implementation  of  these  standards,  or  any  means  of  mandating 
such  actions  across  the  DoD. 

The  STANAG  is  an  attempt  by  NATO  to  document  a  common  high  level 
architecture  and  functional  description  of  a  UAS.  Additionally,  the  document  provides  a 
detailed  explanation  of  the  major  GCS  interfaces.  While  this  document  is  a  step  in  the 
right  direction,  it  does  not  offer  enough  detail  to  ensure  interoperability  among  GCSs 
built  according  to  its  direction.  Also,  the  current  revision  of  the  STANAG  does  not  offer 
many  guidelines  related  to  human-machine  interfaces,  or  an  approach  to  their 
commonality. 

A  survey  of  current  GCSs  reinforces  the  lack  of  commonality  across  the  DoD. 
Even  UASs  of  similar  sizes  and  missions  utilize  non-standard  control  systems  that  do  not 
allow  for  commonality  or  interoperability. 
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III.  PROBLEM  DEFINITION 


A  review  of  the  background  information  reveals  a  problem  that  requbes  further 
research  about  how  to  implement  commonality  and  interoperability  amongst  the  various 
GCSs.  This  project  reviewed  various  aspects  related  to  commonality  and  interoperability 
of  UAS  GCSs,  and  then  scoped  the  efforts  of  the  project  related  to  this  problem  in 
Chapter  IV. 

A.  PROBLEM  IN  GENERAL 

The  lack  of:  1)  common  standards,  2)  design  for  modularity,  and  3)  open  system 
specifications  has  resulted  in  the  problem  of  unique  GCSs  for  UASs,  increasing 
acquisition  expenses,  training  requirements,  and  logistics  footprints.  The  DoD  has  been 
directed  to  develop  a  plan  to  add  commonality  to  UAS  programs  since  the  DoD  cannot 
continue  to  develop,  sustain,  and  operate  UASs  designed  with  stand-alone,  propriety 
architectures.  In  the  absence  of  any  quantifiable  evidence,  former  USD(AT&L)  Mr. 
Young  has  stated,  and  the  GAO  has  concluded,  that  a  common  GCS  for  UASs  may  yield 
cost  savings  benefits  to  the  common  logistics  elements  of  training  and  maintenance. 
Additionally,  operational  effectiveness  has  been  limited  by  the  lack  of  interoperability  in 
UAS  GCSs.  A  push  for  greater  commonality  may  encourage  a  higher  level  of 
interoperability  for  UASs. 

B.  A  DETAILED  DISCUSSION  OF  COMMONALITY  VERSUS 

INTEROPERABILITY 

In  2009,  USD(AT&L)  called  for  a  “common,  open  and  scalable  UAS 
architecture.”  GAO  has  stated,  “common  subsystems  and  components  can  reduce  both 
production  and  life-cycle  costs  as  well  as  improve  interoperability”  [GAO,  2009].  Open 
architectures  are  the  next  frontier  in  GCS  procurement.  “The  new  systems  also  are 
attempting  to  improve  interoperability  by  conforming  to  open  standards  that  facilitate 
communications  with  different  types  of  aircraft”  [Jean,  2009].  These  statements  imply 
commonality  is  a  requirement  for  new  UAS  GCSs. 
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The  second  goal  of  the  Unmanned  Systems  Roadmap  (2007-2032)  is  to 
“emphasize  commonality  to  achieve  greater  interoperability  among  system  controls, 
communications,  data  products,  and  data  links  on  unmanned  systems”  [OSD,  2007].  The 
FY2009-2034  Unmanned  Systems  Integrated  Roadmap  lists  “greater  interoperability 
among  system  controls,  communications,  data  products,  data  links,  and  payloads/mission 
equipment  packages  on  unmanned  systems”  as  its  fourth  goal  [OSD,  2009]. 

Merriam-Webster  defines  commonality  as  possession  of  shared  features  or 
attributes  [Merriam-Webster,  Inc.,  2009].  The  DoD  defines  it  as  “A  quality  that  applies 
to  materiel  or  systems;  a.  possessing  like  and  interchangeable  characteristics  enabling 
each  to  be  utilized,  or  operated  and  maintained,  by  personnel  trained  on  the  others 
without  additional  specialized  training;  b.  having  interchangeable  repair  parts  and/or 
components;  and  c.  applying  to  consumable  items  interchangeably  equivalent  without 
adjustment”  [Joint  Chiefs  of  Staff  (JCS),  2009]. 

Merriam-Webster  defines  interoperability  as  the  ability  of  a  system  to  work  with 
or  use  the  parts  or  equipment  of  another  system  [Merriam-Webster,  Inc.,  2009].  The 
DoD  defines  interoperability  as  the  “a.  The  ability  to  operate  in  synergy  in  the  execution 
of  assigned  tasks,  b.  (DoD  only)  The  condition  achieved  among  communications- 
electronics  systems  or  items  of  communications-electronics  equipment  when  information 
or  services  can  be  exchanged  directly  and  satisfactorily  between  them  and/or  their  users. 
The  degree  of  interoperability  should  be  defined  when  referring  to  specific  cases”  [JCS, 
2009]. 


Interoperability  can  be  achieved  without  commonality.  For  example,  a  DoN 
aircraft  flying  with  an  AN/ARC-210  radio  can  communicate  with  U.S.  Marines  operating 
AN/PRC-117  radios  and  with  ships  using  AN/WSC-5  radios.  Although  each  operator 
has  a  different  radio  made  by  different  vendors,  they  can  all  communicate  through  Ultra 
High  Frequency  (UHF)  Satellite  Communication  (SATCOM).  In  a  similar  manner, 
different  UASs  could  achieve  interoperability  by  using  similar  languages  to  share  data 
with  one  another,  such  as  the  Common  Data  Link  (CDL)  or  the  Tactical  Common  Data 
Link  (TCDL). 
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Commonality  can  also  be  achieved  independent  of  interoperability.  Use  of  the 
same  display  or  joystick  in  different  GCSs,  for  example,  would  provide  commonality 
from  a  hardware  perspective.  Advantages  of  this  level  of  commonality  include  the 
economy  of  scale  and  the  reduced  logistics  footprint  of  a  singular  component.  This  type 
of  commonality  would  not  improve  interoperability. 

STANAG  4586  defines  five  LOIs  for  UASs.  It  goes  on  to  say  that  maximum 
operational  flexibility  can  be  achieved  if  the  GCS  supports  these  LOIs  with  different 
UAVs.  Definitions  of  these  LOIs  can  be  found  in  Table  1.  Figure  13  illustrates  the 
perspectives  of  these  LOIs.  As  shown,  Level  1  can  be  achieved  through  the  use  of 
common  or  compatible  file  transfer  protocols  and  message  or  imagery  formats. 


Figure  13.  Level  of  Interoperability  Perspective 

This  figure  illustrates  the  relationships  of  the  five  LOIs  as  outlined  in  STANAG  4586.  These  levels  vary 
from  the  lowest  interoperability  level  of  1,  where  two-way  communication  between  the  GCS  and  the  GIG 
allow  sharing  of  payload  data,  to  the  highest  interoperability  level  of  5,  where  a  GCS  would  be  capable  of 
launch  and  recovery  of  multiple  UAVs.  Figure  from  [PEO(U&W),  2009]. 


STANAG  7085  Interoperable  Data  Links  for  Imaging  Systems  outlines  the 
requirements  for  Level  1  interoperability  compliance.  It  defines  interoperable  interfaces 
for  UAV  sensors  as  well  as  compliant  data  link  and  communications  protocols  [NATO, 
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2004],  The  DoD  has  adopted  the  CDL  and  TCDL  for  sharing  sensor  data  aeross  the 
Global  Information  Grid  (GIG).  Use  of  these  links  should  ensure  that  UASs  meets  Level 
1  interoperability.  This  should  enable  more  forces  to  receive  sensor  data  from  compliant 
UASs. 


Level  1  interoperability  would  be  a  good  starting  requirement  for  all  UASs. 
Sharing  sensor  data  is  necessary  to  let  forces  operating  in  the  area  with  the  UAS  make 
decisions  quickly.  This  sensor  data  can  also  be  used  by  military  commanders  to  make 
decisions  regarding  close  air  support  and  time  sensitive  targets.  Level  1  interoperability 
allows  decision  makers  to  have  more  data  to  support  their  decision.  However,  indirect 
sharing  of  data  takes  time  and  requires  others  to  process  and  relay  the  sensor  data.  Level 
2  would  allow  direct  sharing  of  sensor  data  with  those  in  direct  communication  with  the 
UAS.  This  direct  link  is  illustrated  by  the  one-way  arrow  from  the  air  vehicle  to  the  ship. 
Payload  data  is  sent  directly  to  the  receiving  entity.  Level  3  would  allow  any  GCS  in 
direct  communication  with  the  UAS  to  control  the  sensor,  aim  the  cameras  or  identify  a 
target  location.  The  two-way  arrow  indicates  the  commands  to  control  the  sensor  and  the 
data  transmitted  in  response.  Level  4  allows  for  control  of  the  air  vehicle  itself  Again  a 
two-way  arrow  indicates  that  commands  are  sent  to  the  air  vehicle  and  status  updates  are 
returned  to  the  operator.  For  a  GCS  to  control  both  the  sensor  and  the  vehicle,  it  must  be 
Level  3  and  Level  4  interoperable  [NATO,  2007].  Level  4  interoperability  does  not 
implicitly  include  Levels  1  through  3. 

For  Level  2  through  Level  5,  the  tenets  of  STANAG  4586  apply.  This  document 
calls  for  the  implementation  of  standard  interfaces  to  allow  a  GCS  the  flexibility  to 
communicate  with  various  UAVs.  The  use  of  standard  interfaces  could  also  facilitate  the 
integration  of  common  components  from  various  sources  into  the  GCS.  This  would 
foster  competition  and  creativity  in  the  development  of  components  and  modules  for  use 
in  GCSs. 

The  One  System  Ground  Control  Station  (OSGCS),  built  by  AAI,  is  an  example 
of  a  common  GCS.  The  OSGCS,  shown  in  Figure  14,  is  currently  used  by  the  U.S.  Army 
and  U.S.  Marine  Corps  on  the  Shadow,  Hunter,  Pioneer,  Raven,  Predator  and  Sky 


38 


Warrior  platforms  [AAI  Corp.,  2009].  The  OSGCS  has  achieved  interoperability  through 
commonality.  The  same  control  station,  with  common  hardware  and  human  interface,  is 
used  by  different  air  vehicles. 


Figure  14.  The  One  System  Ground  Control  Station 

This  figure  shows  the  OSGCS  installed  in  a  mobile  vehicle  (left)  and  a  closer  view  of  this  system  in 
operation  (right).  The  OSGCS  is  an  example  of  an  attempted  common  ground  system.  Figure  from  [AAI 

Corp.,  2009]. 

The  DoD  could  mandate  that  all  UASs  utilize  the  OSGCS.  This  would  provide 
many  advantages.  All  UAS  operators  and  maintainers  trained  on  the  common  OSGCS 
would  be  able  to  work  with  any  UAS.  One  supply  system  may  be  able  to  support  all 
UAS  GCSs,  reducing  the  logistics  footprint.  On  the  other  hand,  mandating  the  use  of  the 
OSGCS  would  create  a  monopoly.  Competition  and  innovation  would  be  stifled.  In  the 
long  term,  the  DoD  could  end  up  overpaying  for  outdated  technology  as  no  incentives 
would  exist  to  constantly  improve  the  OSGCS. 

An  open-source  GCS  could  be  developed  as  a  one-size-fits-all  GCS.  The  OSGCS 
could  be  a  model  for  such  a  system,  but  this  system  should  be  open  for  multiple  vendors 
to  compete  to  support  the  entire  system  or  components  of  the  system.  This  would  allow 
the  advantages  of  commonality  while  encouraging  competition  and  innovation. 

The  disadvantage  of  a  one-size-fits-all  approach  to  UAS  GCS  is  the  tradeoffs  that 
must  be  made.  If  every  UAS  needed  to  use  the  GCS,  then  it  would  optimize  a  common 
solution  to  all  UAS  needs.  No  individual  system  would  be  optimized,  as  compromises 
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would  need  to  be  agreed  to  by  all  programs.  In  the  same  manner  that  manned  aircraft 
have  differences,  UASs  may  have  enough  differences  to  make  a  single  system  an 
unacceptable  solution. 

A  common  GCS  could  allow  the  operator  to  control  those  functions  of 
interoperable  air  vehicles  that  are  deemed  as  common  functions.  Table  2  shows  common 
functions  as  well  as  vehicle  or  payload  specific  functions  as  defined  by  STANAG  4586. 
Control  of  common  functions  could  be  allocated  to  a  common  GCS  or  an  LOI  of  4  could 
be  the  benchmark,  allowing  the  use  of  compliant  GCSs  to  control  compliant  air  vehicles. 


Table  2.  Common  versus  Vehicle-Specific  Functions  of  UAS 

This  table  lists  UAS  functions  that  are  typically  considered  common  to  all  UAS  as  well  as  those  considered 
to  be  functionally  specific  based  on  the  phase  of  the  UAS  mission.  Table  from  [NATO,  2007]. 


Mission  Phase 

Common  Functions 

Vehicle-Specific  Functions 

Pre-flight 

Interoperable  Mission  Planning 
Mission  Plan  /  Verify  Upload 
Process. 

Common  Built-In-Testing  (BIT). 
Mission  Go  /  No-go 

Vehicle  Availability. 

Flight  Plan  Validation. 

Lost  Link  Strategy. 

Vehicle  Specific  BIT. 

Payload  Configuration  Validation  &  BIT 
checks. 

Pre-flight  Checkout  and  Initialisation. 
Downloaded  Mission  Plan  Validation. 
UCSA/ehicle  Communications. 

Clocks  Synchronization  (Air  Vehicle  &  UCS). 

Takeoff 

Local  ATC  Communications. 
Checklists  Complete  Validation. 
UCS/UAV  Communications 
Validation. 

T akeoff  Clearance  Acquisition. 

Ground  Traffic  PatterrVPIan  Execution. 

Ground  Operations  Safety  Constraints 
Monitoring. 

Launch. 

Abort  Sequence  Manaqement. 

Ingress  /  Egress 

Mission  Execution  Monitoring. 

Active  Emitters  (e  g.,  radar) 
Activation. 

UAV  Vehicle-Specific  Handoff  Data 
Management. 

Prime  Mission  Area 
(Target  Area) 

Generic  Payload  Control. 

Payload  Data  Handling. 

Mission  Execution  Monitoring. 

System  Status  Summary 

Information. 

Detailed  System  Status  Monitoring. 

Payload  Specific  Control  &  Monitoring. 

Payload  Specific  Data  Handling 

Approach  /  Landing 

ATC  Coordination. 

Recovery  Procedures  Execution. 

Approach  Flight  path  Acquisition  and 
Maintenance. 

Landing  Sequences  Execution. 

Taxi  Sequence  Execution. 

Shutdown  /  Safing  Checklists  &  Procedure 
Execution. 

Post-Mission  Reporting 

Mission  Execution  Summary 

Report. 

Vehicle  Maintenance  Status  Report. 

Phase-independent  In¬ 
flight 

UAV  handoff  anxjng  UCSs 
Management. 

Mission  Execution  Monitoring. 

Mission  Phase  Monitoring. 

General  Health  &  Status  Monitoring 
(H&SM)  and  Warning. 

Dynamic  Flight  Path  Replanning. 
Multiple  (Possibly  Different)  Aircraft 
Control. 

Data  Recording  /  Buffenng. 

GDT  Control,  Status,  &  Initialisation. 

Detailed  Health  &  Status  Monitoring. 

Lost  Link  Strategy  Execution  and  Monitoring. 
Operator  Control  Modes  Management. 

CBIT  (Continuous  Built-In-Tests)  Across 
Subsystems. 

Differential  GPS  Corrections. 
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Commonality  requirements  eould  be  aehieved  by  implementing  a  eommon 
subsystem.  If  GCSs  used  the  same  display  subsystem,  eommonality  would  be  improved. 
However,  interoperability  of  these  GCSs  would  not  ehange.  Using  a  single-souree 
proprietary  display  could  result  in  a  monopoly,  and  the  idea  of  effective  use  of 
acquisition  resources  may  not  be  realized. 

Interoperability  could  be  achieved  without  commonality.  If  interoperability  is 
indeed  the  driver  for  the  memo  from  USD(AT&L),  then  commonality  may  not  be 
required.  However  interchangeable  parts,  components,  or  subsystems  could  enable 
interoperability  of  systems.  Moreover  commonality  in  GCSs  could  reduce  the 
duplication  of  efforts  in  development.  It  could  also  lead  to  an  economy  of  scale  through 
larger  production  runs  of  common  components  and  systems. 

C.  ELEMENTS  INFLUENCING  COMMONALITY  AND 

INTEROPERABILITY 

In  order  to  better  understand  the  problem,  a  number  of  elements  influencing 
commonality  and  interoperability  in  UAS  GCSs  were  identified.  These  elements  are 
considered  to  have  significant  roles  in  the  ability  to  achieve  commonality  and 
interoperability  in  GCSs.  Once  the  elements  were  adequately  explored,  the  list  was 
scoped  down  in  Chapter  IV  for  further  analysis  in  the  latter  portions  of  the  report. 

1.  Airframe  Size  and  Groupings 

UASs  are  currently  categorized  into  five  groupings  per  the  Joint  UAS  (JUAS) 
Center  of  Excellence  (COE)  [JCS,  2006].  These  groupings  are  based  on  weight, 
operating  altitude,  and  speed  of  the  air  vehicle.  Group  1  UASs  are  relatively  small 
systems  that  operate  at  lower  altitudes  and  slower  airspeeds  than  other  groups.  Group  1 
systems  are  usually  operated  directly  by  the  unit  that  requires  the  video  or  imagery. 
Group  2  systems  are  heavier,  operate  at  altitudes  higher  than  Group  1,  and  have  payloads 
that  are  more  capable.  Group  3  systems  are  even  heavier,  up  to  1320  pounds,  and  can 
operate  up  to  18,000  feet  Mean  Sea  Eevel  (MSE).  Group  4  systems  weigh  more  than 
1320  pounds,  and  fly  up  to  18,000  feet  MSE.  Group  5  UASs  fly  above  18,000  feet 
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[USMC  Combat  Development  Command,  2009].  Table  3  shows  this  data  in  a  tabular 
form. 


Table  3.  UAS  Categorization  in  Groups 

This  table  shows  the  UAS  category  based  on  speed,  weight  and  altitude.  Group  1  includes  the  small 
handheld  UASs,  while  Group  5  includes  the  large  high-altitude  UASs.  Table  after  [USMC  Combat 

Development  Command,  2009]. 


UAS 

Category 

Maximum 
Gross  Takeoff 
Weight  (lbs) 

Normal 
Operating 
Altitude  (ft) 

Speed 

(KIAS) 

Representative  UASs 

Group  1 

0-20 

<  1200  AGL 

100 

WASP  III,  TACMAV,  RQ- 
I4A/B,  BUSTER, 

BATCAM,  RQ-IIB, 

FPASS,  RQ-I6A,  Pointer, 
Aqua/Terra  Puma 

Group  2 

21-55 

<  3500  AGL 

<250 

ScanEagle,  Silver  Fox, 
Aerosonde 

Group  3 

<  1320 

<  18,000  MSL 

STUAS,  RQ-7B,  RQ-15, 
XPV-l,XPV-2 

Group  4 

>  1320 

Any 

Airspeed 

MQ-5B,  MQ-8B,  MQ- 
lA/B/C 

Group  5 

>  18,000  MSL 

UCAS,  MQ-9A,  RQ-4,  RQ- 
4N 

Group  1  UASs  are  often  launehed  by  hand  or  rail  and  operate  LOS  with  the  unit 
that  launehed  it.  Figure  8  shows  an  example  of  a  GCS  for  this  type  of  UAS.  This 
partieular  GCS  ean  operate  a  Raven  or  Wasp  UAS.  Group  1  UASs  benefit  from  a 
handheld  GCS.  Sueh  a  system  enables  a  unit  to  earry  both  the  air  vehiele  and  the  GCS 
along  until  the  system  needs  to  be  deployed.  If  a  larger,  eommon  GCS  were  mandated,  it 
eould  reduee  the  mobility  of  the  unit  and  inerease  its  ehanee  of  deteetion.  It  would  also 
inerease  the  manpower  requirements  of  the  handheld  UAS.  For  example,  a  vehiele 
installed  GCS  may  be  overkill  for  Group  1  UASs.  The  benefits  of  commonality  may  well 
be  offset  by  the  reduced  capabilities  that  were  originally  designed  into  these  smaller 
systems. 
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Larger  UASs,  especially  those  in  Groups  4  and  5,  are  able  to  operate  in  both  LOS 
and  OTH  modes  of  communication.  Because  of  the  air  vehicle  size  and  payload 
capabilities,  larger  vehicles  often  require  both  a  remote  pilot  and  a  sensor  operator. 
Chapter  ILL  shows  some  examples  of  larger  UAS  GCSs.  Such  GCSs  are  not 
man-portable.  They  are  installed  in  either  a  vehicle  or  a  structure.  These  systems  are 
envisioned  to  be  in  operation  for  many  years.  They  also  carry  larger  LCC  than  those  in 
Group  1.  Small  gains  in  efficiencies  or  small  reductions  in  costs  could  translate  to  large 
benefits  if  commonality  and  interoperability  are  applied  to  the  large  UASs. 

Requiring  a  common  GCS  to  operate  with  all  UASs,  regardless  of  size  or 
grouping,  may  be  counter-productive.  The  requirements  and  capabilities  of  a  Group  5 
UAS  will  dictate  a  GCS  with  greater  capabilities  than  a  Group  2  UAS.  For  this  reason,  a 
Group  5  GCS  will  have  extra  features  that  a  Group  2  GCS  does  not  require.  UAS 
capabilities  should  be  considered  along  with  the  potential  benefits  of  commonality. 
Commonality  involves  compromise,  and  what  works  for  a  Group  2  UAS  may  provide 
insufficient  capability  for  a  Group  5  UAS. 

2.  Air  Vehicle  Control  versus  Mission  Specific  Payload  Control 

As  identified  in  STANAG  4586,  discussed  in  Chapter  II.C,  each  UAS  has  five 
distinct  elements:  the  air  vehicle  element,  the  payload  element,  the  data  link  element,  the 
GCS  element,  and  the  launch  and  recovery  element.  Three  of  these  five  elements  address 
air  vehicle  functions.  These  are  the  air  vehicle  element,  the  payload  element,  and  the 
launch  and  recovery  element.  This  section  addresses  how  commonality  may  affect 
control  of  the  air  vehicle  portion  of  the  UAS,  including  the  launch  and  recovery  element 
and  the  payload  element. 

The  air  vehicle  control  element  can  be  impacted  by  commonality  through 
identifying  common  or  standard  interfaces  between  the  air  vehicle  and  the  GCS.  This 
will  also  lead  to  increased  interoperability.  The  payload  element  can  be  impacted  by 
commonality  in  the  same  way.  The  most  direct  element  that  could  be  common  that 
would  impact  both  the  air  vehicle  control  and  the  payload  element  is  the  data  link 
element.  It  would  require  both  the  air  vehicle  control  and  the  payload  element  to  utilize 
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message  traffie  that  has  been  standardized.  However,  this  eommon  standardization  may 
require  additional  hardware  and  software  on  the  GCS  and  the  air  vehiele  to  be  able  to 
eonvert  it  to  and  from  the  eommon  message  traffic.  Standardized  message  traffic  has 
been  identified  in  STANAG  4586.  STANAG  4586  contains  appendices  that  address 
standards  for  interoperability.  One  addresses  the  Data  Link  Interface  (DLI)  and  the  other 
addresses  the  Command  and  Control  Interface  (CCI).  The  standardization  of  the  CCI  is 
intended  to  achieve  interoperability  between  the  UAS  and  the  C4I  users.  There  is  no 
standardization  to  allow  mission  specific  payload  message  traffic  to  be  interoperable,  so 
there  is  less  leverage  for  commonality  from  a  mission  payload  standpoint.  Commonality 
could  be  leveraged  to  achieve  interoperable  CCI. 

The  2003  NDIA  report  identified  issues  for  the  air  vehicle  control  interfaces  that 
currently  exist  with  respect  to  commonality: 

•  UAV  CONOPS  are  inconsistent  in  their  approach  to  AV  C2  interfaces 

•  No  formalized  C2  specific  requirements 

•  UAV  manufacturers  have  proprietary  data  concerns 

•  Compatibility  with  external  interfaces  has  not  been  established 

•  Adaptability  to  future  systems  is  not  embedded 

•  Backward-compatibility  has  not  been  addressed 

•  C2  interface  training  is  different  for  each  UAV 

For  current  UASs,  the  air  vehicle  control  interface  is  exclusively  located  at  the  GCS  for 
each  system.  Therefore,  these  challenges  must  be  addressed  in  the  GCS  design. 

The  2003  NDIA  report  also  identified  the  following  issues  for  the  mission  specific 
payload  interfaces  that  currently  exist  with  respect  to  commonality: 

•  Payload  controllers  see  only  their  payloads 

•  Imagery  products  use  common  standards,  most  other  information  exchange  is 
non-standard 
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•  Mechanism  for  communicating  with  payloads  is  unique  for  almost  all  existing 
platforms 

•  Payload  contention  for  vehicle  control  addressed  by  human  operators 

•  Information  assurance  limited  to  encryption  and  human  judgment 

•  Bandwidth  issues  are  generally  static 

•  Any  platform-platform  interactions  within  constraints  imposed  by  the 
communications  links,  doctrine,  and  CONOPS  are  human-mediated 

The  report  specifically  identifies  that  “Tasking  is  disjoint  for  all  payloads.  There  is  no 
standard  method... for  making  generic  requests  for  information”  [NDIA,  2003]. 

While  there  are  many  benefits  that  can  be  achieved  with  commonality  in  the  air 
vehicle  control  and  mission  specific  payload  domains,  there  are  still  many  challenges 
associated  with  each  respective  domain.  However,  based  upon  the  current 
standardization  that  has  already  been  addressed  with  the  STANAG  4586,  it  is  anticipated 
that  the  air  vehicle  control  interface  is  more  likely  to  benefit  from  commonality  efforts  at 
this  time. 

3.  Human-Machine  Interface 

The  Human-Machine  Interface  (HMI)  for  UASs  consists  of  the  controls  and 
displays  that  the  operators  use  to  interact  with  the  system.  Controls  and  displays  with  a 
common  functional  and  physical  architecture  provide  progress  towards  meeting  the  tenets 
of  the  ADM.  “We  can  provide  flexibility  to  adapt  the  man-machine  interface  for  specific 
Military  Service’s  Concepts  of  Operations  while  maintaining  commonality  on  the 
underlying  architecture  and  computing  hardware.... These  improvements  can  also  reduce 
training  requirements,  decrease  training  time,  and  increase  the  pool  of  UAS 
pilots/operators”  [USD(AT&L),  2009]. 

Some  UASs  may  not  be  a  good  candidate  for  common  GCS  controls  and  displays. 
For  instance,  small  hand-launched  UAVs  may  require  a  simple  handheld  remote 
conrtroller  and  a  laptop  computer  for  sensor  display.  It  is  unlikely  that  the  WASP  (0.7 
pounds)  controls  and  displays  would  provide  the  required  functionality  for  BAMS 
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(32,000  pounds).  Additionally,  fixed  wing  UAS  controls  may  not  work  for  rotary  winged 
UASs. 


Controls  may  consist  of  a  joystick,  keyboard,  mouse,  trackball,  and  in  some  cases 
foot  pedals  and  throttles.  All  of  these  controls  may  not  be  required  and  are  dependent 
upon  the  UAS  mission  and  type.  All  GCSs  pass  commands  to  UAVs  via  one  of  two 
different  methods.  The  first  method  is  the  legacy  controlled  technique  where  a  pilot 
makes  control  corrections  on  a  throttle  and  joystick  and  these  control  positions  are 
transmitted  to  the  UAV  and  provided  as  the  inputs  to  the  UAV  flight  control  surfaces. 
The  second  method  is  the  newer  directed  technique  where  a  waypoint  is  transmitted  to 
the  UAV  and  the  onboard  flight  control  computer  determines  and  commands  the  control 
surface  changes  necessary  for  the  UAV  to  intercept  the  waypoint.  UAVs  that  are 
directed,  vice  controlled,  do  not  have  a  joystick  or  foot  pedals.  This  leads  to  the 
conclusion  that  all  GCS  controls  may  not  be  able  to  be  common.  For  example,  some 
UAVs  can  be  commanded  by  remote  control  type  controllers,  as  shown  in  Figure  15. 
This  type  of  specialty  control  may  not  be  a  good  candidate  for  a  common  control  and 
would  only  work  for  specific  UAVs.  Additionally,  control  inputs  for  directed  UAVs 
could  be  accepted  Ifom  touch  screen  displays,  blurring  the  line  between  controls  and 
displays. 
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Figure  15.  Remote  Control  used  on  British  Army  Hermes  450  UAV  GCS 

The  red  circle  highlights  a  remote  control  type  controller  such  as  could  be  used  to  control  a  model 
airplane.  This  is  one  type  of  control  that  is  present  in  some  unmanned  systems.  Figure  after  [IHS  (Global) 

Limited,  2009]. 


As  discussed,  there  are  currently  different  methods  of  implementing  the  pilot 
HMI.  Some  GCSs,  sueh  as  that  of  Predator  and  Reaper,  have  a  controlling  type  pilot 
interfaee.  That  is,  the  interface  is  designed  to  give  the  air  vehiele  operator  the  feel  and 
display  of  being  in  a  cockpit.  The  air  vehiele  is  issued  commands  through  a  stick  and 
throttle  system  actually  sending  flight  system  controls  to  pitch,  roll,  and  yaw  the  aircraft 
like  a  pilot  would  in  a  eockpit  of  a  traditional  aireraft.  A  visual  display,  such  as  in 
General  Atomics’  new  Advaneed  Cockpit  Ground  Control  System,  “expands  the 
operators’  field  of  view  to  120  degrees  from  30  degrees  with  a  panoramic  synthetic  view 
generated  by  software  from  a  military  mapping  server,”  simulating  the  view  a  pilot  would 
see  out  the  eoekpit  window  if  the  operator  was  there  [Jean,  2009].  Similarly,  Raytheon 
Corporations’  new  Common  Ground  Control  System  is  “laid  out  in  a  eoekpit-like 
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configuration”  and  “three  wide-sereen  displays  give  pilots  and  sensor  operators  a  120- 
degree  view  of  the  battlefield”  [Jean,  2009]. 

As  previously  mentioned,  a  eompletely  different  type  of  HMI  for  UAVs  is 
eommand  by  direction,  which  is  currently  used  by  the  USAF  Global  Hawk  and  planned 
in  the  USN  BAMS  UAS.  This  newer  directed  method  of  eommand  input  allows  the  user 
to  set  desired  states  of  the  aireraft,  such  as  altitude,  eourse,  and  airspeed.  It  is  more 
likened  to  flying  the  UAS  through  an  autopilot.  Whereas  in  a  controlled  type  interfaee, 
the  pilot  pulls  the  stiek  back  to  gain  altitude  and  then  pushes  it  forward  to  level  off,  in  a 
directed  type  interfaee,  the  pilot  simply  sets  the  desired  altitude,  sends  the  eommand  to 
the  UAV  and  the  vehicle  eomputes  all  the  inputs  to  the  eontrol  surfaees  ineluding  rates, 
and  maneuvers  itself  to  get  to  the  desired  altitude.  This  allows  less  hands-on  eontrol  and 
more  monitoring  and  usually  allows  the  user  to  set  waypoints  (positions  in  3-D  spaee) 
that  the  air  vehiele  will  fly  to  as  a  course. 

Another  area  that  is  different  between  the  two  types  of  systems  is  in  the  terminal 
area  (the  phase  of  flight  near  the  ground,  both  takeoff  and  landing).  A  eontrolled  UAV 
uses  GCS  stick-and-rudder  eommands  to  takeoff  and  land  and  usually  provides  pilots 
with  a  eamera  view  of  the  runway  in  front  of  them  to  takeoff  and  land  manually.  A 
direeted  type  system  will  direet  the  UAV  to  the  runway,  and  onee  there,  issue  a  takeoff 
eommand,  where  the  UAV  will  do  all  of  its  own  eontrol  adjustments  to  maintain  its  pre¬ 
planned  takeoff  route  while  the  pilot  monitors  its  progress.  These  are  two  dramatieally 
different  appro aehes  to  the  takeoff  and  landing  phases  of  flight. 

The  DoN  is  going  down  the  path  of  a  directed  point-and-eliek  interfaee.  RDML 
William  Shannon,  Program  Executive  Offiee  Unmanned  Aviation  and  Strike  Weapons 
(PEO(U&W))  noted,  “When  you  say  GCS,  many  folks  pieture  a  pieee  of  hardware.  Eor 
the  USAE,  it  really  is  a  eoekpit  on  the  ground.  But  we  don’t  fly  our  UASs.  None  that  we 
have  or  are  planning  have  any  stiek-and-rudder  type  of  flight-it's  preplanned  or  point  and 
eliek”  [Warwiek  &  Chavanne,  2009].  As  this  report  examines  areas  of  eommonality 
aeross  UASs,  the  GCS  operating  system  will  be  a  key  element.  RDML  Shannon 
highlights  the  DoN  philosophy  on  GCSs:  “Really,  it  ought  to  be  thought  of  as  a  software 
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application  that  can  operate  on  any  platform,  from  consoles  to  handhelds.  This  thing  we 
call  a  GCS  is  really  a  GCS  application  you’d  be  able  to  employ  on  multiple  hardware 
platforms.  That’s  where  we’d  like  to  go”  [Warwick  &  Chavanne,  2009]. 


When  it  comes  to  displays,  an  example  of  a  GCS  using  commercial,  militarized, 
and  rack  mounted  displays  is  shown  in  Figure  16.  The  standard  commercial  displays 
are  highlighted  with  a  red  border.  The  militarized  and  rack  mounted  displays  consist  of 
two  larger  displays,  one  over  the  other,  and  two  smaller  displays  shown  side  by  side. 
This  demonstrates  a  lack  of  hardware  commonality  in  that  even  within  a  single  GCS,  the 
operator  can  use  three  different  display  types. 


Figure  16.  Predator  Ground  Control  Station 

Inside  a  Predator  ground  control  station  at  Creech  Air  Force  Base  showing  commercial  monitors  and  rack 
mounted  militarized  monitor.  Figure  after  [IHS  (Global)  Limited,  2009]. 


Another  HMI  consideration  is  the  way  data  is  displayed  to  the  operator. 
Displayed  data  can  conform  to  the  common  symbology  contained  in  MIL-STD-2525C: 
Common  Warfighting  Symbology  [DoD,  2008].  One  of  the  problems  with 
MIL-STD-2525C  is  that  it  was  originally  published  in  1994  and  was  designed  for  older 
displays  with  low  resolutions.  The  updates  to  the  standard  have  not  kept  pace  with  the 
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technological  advances  realized  by  newer  high  definition  displays.  Using  a  common 
symbology  can  enhance  training  commonality  between  different  UASs.  An  example  of 
common  symbology  tfom  MIL-STD-2525C  is  shown  in  Figure  17. 
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Figure  17.  Examples  of  Common  Symbology 


This  graphic  shows  standard  identities  for  common  sensor  contacts.  Red  denotes  hostile  or  suspect,  yellow 
denotes  pending  or  unknown,  blue  is  friend  and  green  is  neutral.  Figure  from  [DoD,  2008]. 


Additional  considerations  when  discussing  common  HMI  for  GCSs  include 
nonstandard  control  and  display  solutions  such  as  Helmet  Mounted  Displays  (HMDs). 
HMDs  were  considered  by  the  DoD  and  quickly  discounted  due  to  the  added  complexity 
and  the  likelihood  for  motion  sickness,  eye  strain,  and  disorientation.  This  was 
determined  during  a  2004  experiment  at  the  Ames  Research  Center,  Moffett  Field,  CA, 
which  evaluated  UAV  operators  wearing  an  HMD  versus  using  a  conventional  computer 
joystick  to  perform  sensor  target  search  tasks.  “The  subjects’  ability  to  place  the  cursor 
on  a  target  of  interest  (targeting  accuracy)  was  significantly  better  in  the  computer 
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monitor  condition  than  the  HMD.  The  distanee  at  whieh  subjeets  eould  elassify  an 
objeet’s  identity  was  also  signifieantly  better  in  the  eomputer  monitor  eondition. 
Subjeetive  measures  showed  no  overall  differenees  for  self-reported  fatigue,  workload, 
and  situational  awareness.  A  signifieant  disadvantage,  however,  was  found  for  the  HMD 
with  respect  to  self-reported  nausea,  disorientation,  and  oculomotor  strain”  [Morphew, 
Shively,  and  Casey,  2004] . 

The  previously  mentioned  HMI  considerations  must  be  taken  into  aeeount  when 
diseussing  a  eommon  UAS  GCS.  Many  of  the  variations  in  HMI  aspeets  of  GCSs 
manifest  themselves  as  ehallenges  when  looking  for  a  eommon  interfaee. 

4.  Hardware  and  Software  Combination 

The  GAO  report  titled  Improved  Strategic  and  Acquisition  Planning  Can  Help 
Address  Emerging  Challenges  eites: 

The  serviees  have  generally  been  reluctant  to  adopt  common  mission 
management  systems  or  other  interoperability  approaehes  within  similar 
types  or  elasses  of  UAVs.  As  a  result,  it  appears  that  some  UAVs  may  not 
be  fully  interoperable  with  other  UAVs,  with  manned  aireraft  systems,  or 
even  with  eonventional  forees.  For  example,  in  eertain  instanees  ground 
forees  have  not  been  linked  to  or  able  to  utilize  data  generated  by  other 
serviees’  UAVs.  Eaeh  serviee  has  tended  to  initiate  its  own  separate 
development  program,  specifieally  tailored  to  its  own  requirements,  rather 
than  adopting  an  existing  capability  from  another  service.  The  DoD  is 
aware  of  this  problem  and  has  taken  some  steps  to  address  it.  For 
example,  the  DoD  is  evaluating  several  areas,  ineluding  vehiele 
development,  training,  and  data  sharing,  to  determine  if  improvements  in 
these  areas  will  inerease  UAV  interoperability.  [GAO,  Mareh  2005] 

While  vehiele  development,  training,  and  data  sharing  are  being  addressed  to  determine  if 
improvements  in  these  areas  will  inerease  UAV  interoperability,  it  is  evident  that  the 
DoD  will  need  to  evaluate  the  hardware  and  software  eombinations  to  achieve  that  goal. 
However,  a  ehallenge  for  eommon  hardware  or  software  for  the  DoD  is  a  result  of  unique 
requirements  for  eaeh  serviee. 

The  Joint  Unmanned  Combat  Air  Systems  (JUCAS)  program  was  initiated  as  a 
USAF  and  USN  program  for  attaek  of  land  targets: 
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Concerned  about  the  accelerated  schedule  and  a  lack  of  synergy  in  the 
separate  Air  Foree  and  Navy  efforts,  Offiee  of  the  Seeretary  of  Defense 
officials  intervened  to  reconcile  requirements  and  funding  ehallenges  and 
to  improve  oversight.  The  Defense  Advanced  Research  Projects  Agency 
was  designated  to  lead  the  joint  demonstration  program  with  Air  Force 
and  Navy  participation.  Plans  and  strategy  established  a  $4  billion 
demonstration  program  that  would  develop  larger  versions  of  the  Air 
Force  and  Navy  prototypes,  leading  to  an  operational  assessment  in  2007. 

A  common  operating  system  was  to  be  developed  and  both  versions  were 
expeeted  to  also  share  common  subsystems  and  weapons.  The  intent  was 
to  then  offer  alternatives  to  the  services  leading  to  possible  start-up  of 
systems  development  in  2010.  Although  not  elear  at  this  time  <2005>, 
program  direetion  and  content  appears  to  be  again  ehanging.  Congress 
reduced  fiscal  year  2005  funding,  stating  that  the  program  had  not 
properly  eoordinated  with  the  services  and  that  the  focus  should  be  on 
meeting  Air  Foree  and  Navy  requirements.  [GAO,  Mareh  2005] 

Even  with  a  proposed  common  operating  system,  the  services  found  their  respective 
requirements  were  not  being  met.  The  USAF  pulled  out  of  the  program  and  “redirected 
its  development  efforts  towards  a  larger,  stealthy  high-altitude  unmanned  platform.”  The 
USN  decided  to  “eontinue  with  a  more  ‘traditional’  Unmanned  Combat  Air  System 
(UCAS)  design”  [Hewson,  2006].  Even  when  common  hardware  and  software  are 
products  of  a  program,  the  serviees  find  they  do  not  meet  their  requirements. 

A  2003  NDIA  eommon  UAV  arehitecture  study  analyzed  this  problem  and 
identified  some  ehallenges  associated  with  eommonality.  Eor  the  proeessor  arehiteeture, 
the  NDIA  identified  the  following  issues  with  respect  to  commonality: 


•  Eew  common  operational  interfaees 

•  No  universal  conversion  standards 

•  Eittle  baekward-eompatibility  except  within  family 

•  No  multi-level  security 

•  Eittle  common  software 

•  Eew  universal  external  interfaces 

These  issues,  whether  or  not  they  were  allocated  to  software  or  hardware,  would  need  to 
be  addressed  in  order  to  achieve  eommonality.  The  report  reeommended  “developing 
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hardware  independent  software  using  open  hardware/software  arehitectures,  standards 
and  COTS  products”  [NDIA,  2003]. 


Discussions  of  a  common  or  interoperable  GCS  must  take  into  consideration  the 
manifestation  of  the  commonality.  Decisions  must  be  made  whether  hardware 
commonality,  software  commonality,  or  both  are  required  to  achieve  the  goals  of  the 
DoD. 


5.  Implementation  through  Retrofit  or  New  Acquisition 

To  maximize  acquisition  resources  and  meet  increased  demand.  Congress  and  the 
DoD  have  required  more  commonality  among  UASs.  GAO  has  recommended  “that 
before  initiating  new  unmanned  aircraft  development  programs,  the  Secretary  should 
require  the  services  to  demonstrate  in  their  acquisition  plans  and  strategies  that  they  are 
taking  an  open  systems  approach  and  that  the  potential  for  commonality  has  been 
rigorously  examined”  [GAO,  2009].  Therefore  it  is  assumed  that  future  development  will 
be  required  to  meet  some  minimum  level  of  commonality  and  interoperability. 

As  common  components  and  subsystems  transition  from  development  into 
production,  new  UAS  programs  should  require  their  incorporation.  The  use  of 
off-the-shelf  and  non-development  items  should  be  required  as  well.  Initial  engineering 
development  models  should  be  delivered  with  common  components  and  tested  for 
performance  and  interoperability  [Van  Dyke,  1990].  In  this  manner  future  UAS  GCSs 
can  be  designed  for  commonality. 

Many  options  exist  for  those  GCSs  already  fielded  and  operational.  Forced 
retrofit,  requiring  all  GCSs  to  adopt  the  common  components  or  systems,  would  be  the 
most  extreme  option.  Block  upgrades  could  be  conducted,  taking  smaller  groups  of 
GCSs  and  upgrading  them  to  the  new  common  design.  Individual  GCSs  could  be  made 
common  by  attrition.  In  this  case,  as  systems  fail,  they  could  be  reconfigured  to  a 
common  system.  Introduction  of  common  components  and  modules  into  the  supply 
system  would  be  another  method  of  achieving  commonality  by  attrition.  As  individual 
components  fail,  common  components  and  subsystems  could  be  identified  as  preferred 
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spare  parts  for  replacement.  Finally,  there  is  the  option  to  do  nothing  with  systems  that 
are  already  fielded  and  focus  solely  on  new  acquisition.  Systems  already  fielded  or  far 
enough  in  development  may  be  left  as-is  until  their  retirement  due  to  unplanned  cost 
increases. 

As  stated,  forced  retrofit  would  be  the  most  extreme  option.  It  would  ensure  the 
maximum  level  of  interoperability  in  the  minimum  time.  The  benefits  of  commonality  or 
interoperability  may  not  be  sufficient  to  offset  the  cost  of  a  forced  retrofit.  Negative 
transfer  on  such  systems  could  also  be  expected. 

Negative  transfer  occurs  when  training  on  one  system  interferes  with  the  learning 
of  another.  Habits  in  a  legacy  UAS  could  be  applied  to  the  new  system.  Personnel  who 
operated  legacy  GCSs  could  be  expected  to  rely  on  years  of  experience  with  those 
systems,  even  if  that  experience  was  no  longer  relevant  after  the  retrofit.  This  situation  is 
worst  when  displays  and  interfaces  between  the  two  are  similar,  and  when  similar  actions 
on  the  legacy  system  have  very  different  consequences  in  the  new  one  [Lydall  & 
Wickens,  2005]. 

At  the  first  opportunity,  modifying  GCSs  during  scheduled  or  unscheduled 
maintenance  would  eventually  achieve  commonality  over  time.  Often  this  is  the  DoD’s 
preferred  method  of  implementing  change  because  of  its  low  cost  and  the  timing  of 
modifications  [Crowder,  1992]. 

Modification  by  attrition  would  take  an  even  longer  time  to  fully  implement 
compared  to  first  opportunity.  Only  when  systems  or  components  fail  would  they  be 
modified  to  a  more  common  configuration.  Systems  or  components  with  high  reliability 
may  take  years  to  fail.  However,  the  impact  to  the  end  user  is  minimal.  Only  when  the 
system  has  a  failure,  and  is  thus  already  non-operational,  is  it  taken  off-line  for 
modification. 

Modification  by  attrition  or  first  opportunity  may  increase  the  risk  of  negative 
transfer.  Since  systems  are  not  all  changed  at  once,  it  is  possible  for  an  operator  or 
maintainer  to  work  on  one  configuration  one  day,  and  another  soon  after.  Training  in  the 
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new  configuration  would  be  required,  and  human  error  could  increase  as  personnel  rely 
on  the  way  they  initially  learned  the  system. 

UAS  programs  already  in  development  have  spent  large  amounts  of  money 
developing  GCSs  with  more  under  contract.  Major  changes  to  these  GCSs  may  carry  a 
large  price  tag.  It  may  be  more  beneficial  to  finish  these  systems  and  leverage  lessons 
learned  Irom  legacy  and  new  systems.  On  the  other  hand,  the  number  of  proprietary 
GCSs  continues  to  grow.  With  no  concern  for  commonality,  the  problem  will  only  get 
worse.  Directives  are  in  place  and  the  services  need  to  respond.  Doing  nothing  is  not  an 
acceptable  option. 

6.  Department  of  Defense  Multiservice  Cooperation 

As  stated  within  FY2009-2034  Unmanned  Systems  Integrated  Roadmap,  “...the 
Roadmap  lays  out  a  vision  in  terms  of  potential  missions  that  could  be  performed  by 
unmanned  systems,  the  desired  fimctionality  and  performance  needed  by  the  systems  to 
perform  those  missions,  and  the  technology  advancements  needed  to  achieve  such 
performance”  [OSD,  2009].  It  is  in  this  document  that  the  Office  the  Secretary  of 
Defense’s  vision  is  communicated  for  UASs.  This  vision  addresses  the  following  areas 
[OSD,  2007]: 

•  Conducting  a  more  integrated  approach  to  identifying  how  unmanned  systems 
can  be  optimized  to  support  a  greater  set  of  mission  areas 

•  Identifying  those  common  areas  of  technology  maturation  that  can  lead  to 
performance  improvements  in  all  domains 

•  Identifying  the  technology  enablers  needed  to  foster  the  ability  to  conduct 
collaborative  operations  between  multiple  unmanned  systems  in  multiple 
domains 

Areas  well  suited  for  commonality  will  be  investigated  as  a  candidate  for 
implementation.  By  identifying  those  common  technology  areas  for  the  common  GCS,  a 
more  integrated  approach  to  supporting  a  greater  set  of  mission  areas  can  be  achieved. 

As  the  OSD  Roadmap  states,  UASs  can  perform  persistent  Intelligence, 
Surveillance,  and  Reconnaissance  (ISR),  a  capability  that  fieet  commanders  have  never 
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had  before.  “They  can  be  rapidly  and  dynamically  re-tasked  to  other  areas  with  a  higher 
priority,  and  are  currently  enjoying  tremendous  freedom  of  action  in  uncontested 
airspace.  Because  of  this,  UASs  are  proliferating  throughout  the  theater  of  operations 
supporting  both  the  JFC  and  ground  combatant  commanders.  To  shape  their  battle  space 
and  make  decisions  affecting  the  outcome  of  their  engagements,  commanders  at  all  levels 
require  situational  understanding  and  UASs  can  provide  a  variety  of  these  components. 
They  increase  the  situational  awareness  (SA)  of  commanders  through  intelligence, 
surveillance,  reconnaissance,  and  target  acquisition”  [OSD,  2009]. 

However,  all  DoD  services  do  not  utilize  UASs  in  the  same  manner.  Each  service 
will  employ  a  UAS  to  meet  its  specific  operational  needs.  “All  four  Services  employ 
multiple  UASs  for  a  variety  of  tasks  and  missions  including  fleet,  perimeter  security, 
tactical  surveillance,  weapons  spotting,  targeting,  and  weapons  guidance,  as  well  as  a 
host  of  other  unit  mission-specific  tasks”  [OSD,  2009].  Although  there  are  similar  UASs 
across  the  DoD,  each  service  will  utilize  their  UASs  in  a  unique  manner  to  meet  their 
specific  operational  needs.  This  lack  of  a  common  joint  operational  concept  is  one  of  the 
challenges  of  creating  a  common  UAS  GCS. 

The  NDIA  2003  report  that  presented  challenges  with  commonality  also  identified 
CONOPS  as  an  issue  associated  with  commonality  across  the  DoD  services.  “There  are 
no  inherent  forces  driving  towards  Concept  of  Operations  (CONOPS) 
commonality.... Operators  will  employ  the  delivered  capabilities  of  each  system  to  meet 
their  training  and  warfighting  requirements,  and  while  similarities  will  be  apparent,  there 
is  no  driving  need  for  CONOPS  commonality  across  inherently  different  systems” 
[NDIA,  2003].  Although  some  DoD  groups  have  been  working  toward  a  common  UAS 
CONOPS  since  the  NDIA  report  was  released  in  2003,  all  the  services  must  agree  and 
adhere  to  these  CONOPS  before  true  commonality  can  ensue.  A  specific  example  of  the 
commonality  challenge  across  the  DoD  services  is  the  Predator  and  Sky  Warrior  case 
presented  in  Chapter  I.C. 
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7. 


United  States  and  Allied  Cooperation 


NATO  UAS  operations  originated  during  the  mid-1990s.  “Unmanned  aircraft 
presence  in  the  Balkans  theater  of  operations  dates  back  to  1994.  In  1995,  U.S.  Predators 
flew  operationally  for  the  first  time  over  Bosnia.  In  October  and  November  of  1998  U.S. 
Air  Force  RQ-1  Predators  flying  Ifom  Hungary  supported  the  Organization  for  Security 
and  Cooperation  in  Europe  (OSCE)  verification  mission  over  Kosovo.  The  German 
Army  followed  with  CE-289  drones,  based  in  Macedonia.  Soon  afterwards  several  other 
NATO  countries  deployed  their  own  assets”  [Saiz  &  Eewandowski,  2008]. 

“Efficient  utilization  of  the  capabilities  provided  by  the  different  unmanned 
systems  proved  to  be  challenging  with,  in  some  instances,  a  tendency  for 
micromanagement  by  senior  commanders.  Every  single  unmanned  mission  over  the 
Balkans  had  to  be  included  in  the  daily  Air  Tasking  Order  (ATO)  with  the  consequent 
difficulties  of  coordination.  Another  important  obstacle  to  overcome  was  de-confiiction. 
The  situation  got  even  more  complicated  after  the  deployment  of  KEOR  and  the 
increased  helicopter  and  air  transport  activities”  [Saiz  &  Eewandowski,  2008]. 

Currently,  interoperability  between  UASs  within  a  single  nation  does  not  exist,  let 
alone  interoperability  between  multinational  UASs.  “In  an  attempt  to  address  the 
problem  of  interoperability  between  nodes  in  a  multinational  UAV  network,  the  NATO 
STANAG  4586  was  created  to  address  standard  interfaces  of  UAV  control  systems.  In 
its  second  edition,  STANAG  4586  was  conceptualized  to  promote  interoperability 
between  one  or  more  control  stations,  UAVs  and  their  payloads,  and  the  C41  network, 
particularly  in  joint  operational  settings.  STANAG  4586  attempts  to  accomplish  this 
through  implementing  ‘standard  interfaces’,  which  should  not  be  confused  with  HCl. 
The  standard  interfaces  are  essentially  communication  message  sets  between  the  vehicle 
and  a  control  station”  [Cummings,  Kirschbaum,  Sulmistras,  and  Platts,  2006]. 

The  need  for  UAS  interoperability  among  NATO  Alliance  members  is  understood 
and  accepted.  The  implementation  of  this  standard  has  begun.  “Several  vehicles  have 
flown  using  STANAG  software  hosted  on  the  Common  Data  Eink  (CDE)  Systems 
Vehicle  Control  Station,  including  Silver  Eox  (Advanced  Ceramics  Research), 
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Grasshopper  (Xiphos),  Warrior  -  Extended  Range/Multi-Purpose  (ER/MP)  (General 
Atomics  Aeronautical  Systems,  Inc.  (GA-ASI)),  Kingfisher  (BAE  Systems),  and  Shadow 
and  Pioneer  (AAI)  are  to  be  fiown  within  the  year.  The  USN  is  implementing  STANAG 
4586  through  the  Raytheon  Tactical  Control  Station  (TCS)  for  the  VTUAV  RQ-8B  Eire 
Scout”  [Cummings,  et  al,  2006]. 

“STANAG  4586  is  the  only  standard  that  exists  to  promote  interoperability 
across  a  command  and  control  network  of  unmanned  aerial  vehicles.  Such  standards  are 
needed  to  truly  ‘flatten’  the  battlefield  such  that  communications  between  allied  forces 
occur  without  the  significant  uncertainty  and  technical  difficulties  that  exist  in  joint 
operations  today.  The  flexibility  is  lost  when  designing  a  system  to  a  standard  can  be 
countered  both  with  reduced  costs  and  reduced  degrees  of  Ifeedom  for  uncertainty.  This 
is  particularly  true  when  humans  are  in  a  supervisory  control  loop  because  introducing  a 
standard  clearly  identifies  boundaries.  Moreover,  introduction  of  interoperability 
standards  aids  in  simplifying  the  design  process,  as  well  as  the  operation  of  these 
complex  systems”  [Cummings,  et  al,  2006]. 

“The  optimum  synergy  among  the  various  national  UAVs  deployed  requires  close 
coordination  and  the  ability  to  quickly  task  available  UAV  assets,  the  ability  to  mutually 
control  the  air  vehicles  and  their  payloads,  as  well  as  rapid  dissemination  of  the  resultant 
information  at  different  command  echelons.  This  requires  the  employed  UAV  systems  to 
be  interoperable.  In  order  to  enable  interoperability  for  UAV  systems  the  implementation 
of  standards  for  key  system  interfaces  and  functions  is  required.  These  standards  are  laid 
down  in  a  number  of  existing  or  emerging  NATO  STANAGs  and  generally  applied 
commercial  standards  documents”  [Saiz  &  Eewandowski,  2008]. 

NATO  has  attempted  to  implement  some  commonality  standards,  reiterating  the 
fact  that  commonality  and  interoperability  between  the  United  States  and  Allied  countries 
must  be  a  consideration  when  discussing  UAS  GCSs. 
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D.  AREAS  IMPACTED  BY  COMMONALITY  AND  INTEROPERABILITY 


The  previous  section  explored  some  of  the  elements  that  affect  the  capability  to 
achieve  commonality  and  interoperability  in  UAS  GCSs.  This  section  examines  the  areas 
that  are  impacted  if  commonality  and  interoperability  are  achieved.  These  system  areas 
cover  a  wide  range  of  topics  including:  logistical  elements,  cost,  and  mission  capability. 

1.  Training 

There  are  several  advantages  from  commonality  that  are  applicable  to  training. 
Some  advantages  are  consolidation  of  training  courses  and  materials,  increased  reuse  of 
training  materials,  and  shorter  retraining  times  that  can  focus  on  proficiency  for 
assignments  to  common  systems. 

Consolidation  of  ground  training  courses  and  materials,  as  well  as  training 
material  reuse,  has  been  demonstrated  by  the  F-35  JSF  program.  Lockheed  Martin 
Corporation  is  building  a  training  center  at  Eglin  Air  Force  Base,  FL,  which  will  be  used 
by  all  JSF  pilots  and  maintainers.  According  to  Peter  Walker,  project  manager  for 
Lockheed  Martin  simulations,  training,  and  support,  “Even  though  there  are  three  variants 
of  the  aircraft  and  nine  different  countries  involved  with  the  E-35  Joint  Strike  Eighter 
program,  70  percent  of  the  training  is  common”  [Jean,  July  2008]. 

Another  example  of  flight  and  ground  training  courses  and  materials  as  well  as 
training  material  reuse  has  been  demonstrated  by  the  JPATS.  The  JPATS  is  a  set  of 
primary  flight  training  devices  tailored  in  its  design  to  replace  the  USAE  T-37B  and  USN 
T-34C  aircraft  and  their  associated  ground-based  training  systems.  “JPATS  consists  of 
the  T-6A  Texan  II  air  vehicles,  simulators  and  associated  ground-based  training  devices, 
a  Training  Integration  Management  System  (TIMS),  instructional  courseware,  and 
contractor  logistics  support.  The  Services  will  acquire  common  aircraft  and  the 
remaining  components  will  be  as  common  as  possible”  [Global  Security,  1999]. 

The  potential  savings  in  training  time  and  dollars  from  developing  and  fielding 
equipment  with  common  attributes  is  well  understood  in  the  commercial  world, 
especially  where  training  costs  are  high,  such  as  for  airline  flight  crews  [Held,  Newsome, 
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and  Lewis,  2008].  Southwest  Airlines’  decision  to  fly  a  fleet  with  a  single  airframe,  the 
Boeing  737,  simplifies  the  training  of  pilots,  maintainers,  and  flight  attendants  [Treacy  & 
Wiersema,  1994],  This  training  advantage  is  so  important  that  the  company  will  reject 
changes  that  reduce  commonality.  For  example,  “in  more  recent  models  of  737s,  Boeing 
designed  a  ‘glass  cockpit’  with  computer  screens  replacing  old  fashioned  analog  dials. 
But  in  order  to  maintain  interoperability.  Southwest  asked  Boeing  to  program  the  new 
displays  to  look  like  the  ‘old  steam  gauge’  dials  and  indicators  that  are  so  familiar  to 
Southwest  pilots”  [Stieffi,  2005]. 

In  2003,  the  USAF  deputy  chief  of  staff  for  war-fighting  integration  prompted  an 
NDIA  study  group  to  seek  recommendations  from  major  UAV  platform  manufacturers 
on  how  best  to  achieve  a  plug-and-play  architecture  that  would  allow  multiple  unmanned 
aircraft,  sensors,  mission  control,  and  ground  stations  to  work  in  a  common  network.  The 
final  report  stated  that,  “Joint,  interoperable  UAV  systems  must  become  the  norm  for 
operational  planning,  training  and  exercises”  [Erwin,  2003].  The  group  also  wrote,  “The 
Air  Operations  Center  (AOC)  is  becoming  inundated  with  a  proliferation  of  ‘tribal’ 
stovepipes  requiring  ‘tribal ’-unique  training,  configuration-unique  electronics  and 
software,  and  an  ever-increasing  AOC  bandwidth  load  and  ground  station  logistics 
footprint”  [NDIA,  2003]. 

The  U.S.  Army  has  started  to  implement  within-service  commonality  for  UAS 
ground  stations,  which  has  had  a  positive  effect  on  operator  training.  The  U.S.  Army 
flies  all  of  its  unmanned  aircraft  with  the  One  System  Ground  Control  Station  (OSGCS), 
a  technology  that  can  command  different  vehicles  with  a  common  data  link.  Being  able 
to  fly  any  of  the  unmanned  aircraft  systems  using  the  same  interface  reduces  the  training 
time  for  operators,  says  Maj.  Robert  Kadavy,  an  action  officer  in  the  aviation  directorate 
at  U.S.  Army  MQ-IC  Sky  Warrior  headquarters  [Jean,  December  2008]. 

Training  cost  savings  achieved  through  commonality  are  well  understood.  The 
extent  of  these  savings  depends  on  the  specifics  of  the  program.  The  extent  of 
commonality  in  the  HMI  systems  will  directly  affect  the  cost  savings  for  operator 
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training,  while  the  extent  of  eommonality  in  hardware  systems  will  directly  affect  the 
savings  for  maintainer  training. 

2,  Basing 

Commonality  can  improve  basing  within  the  DoD  in  several  key  areas.  Basing 
focuses  primarily  on  locations  for  operational  and  logistical  placement  of  centers  in 
support  of  land  and  amphibious  or  sea  basing  doctrines.  From  the  operational  standpoint, 
commonality  would  focus  on  centralized  air  vehicle  control  centers  and  geographically 
co-located  launch  and  recovery  sites.  From  the  logistical  standpoint,  commonality  would 
focus  on  locations  of  repair  centers,  storage  facilities,  and  training  centers  [USMC 
Combat  Development  Command,  2009].  Even  synergies  of  different  systems  with  partial 
common  elements  or  components  can  contribute  to  some  type  of  beneficial  basing 
results. 


Commonality  and  basing  can  create  several  possible  improvement  areas. 
Commonality  can  affect  basing  by  encouraging  facilities  consolidation,  which  can  reduce 
the  logistical  footprints  of  an  overall  system  by  reducing  geographical  dispersion, 
consolidating  facilities  that  support  the  fleet  systems  (e.g.  repair  centers,  storage 
warehouses,  and  transportation  shipping  mechanisms).  Consolidation  of  training 
facilities  and  use  of  similar  equipment  can  also  affect  basing  of  common  systems  by 
enhancing  and  standardizing  tactics,  techniques,  and  procedures  that  can  enhance  the 
performance  of  the  operator  and  reduce  reaction  or  response  times  that  can  be  significant 
to  mission  success.  These  can  be  easily  controlled  in  a  centralized  location  for  training. 

Centralized  locations  for  intelligence  gathering,  analysis,  filing,  and  distribution 
would  be  facilitated  if  UAS  GCSs  were  common.  Intelligence  centers  can  encompass 
real-time  intelligence  gathering  (networking),  real-time  data  sharing  between  intelligence 
command  posts,  and  provide  expedited  feedback  of  battle  situational  awareness  to 
combat  commanders. 

Common  GCSs,  which  are  also  interoperable,  can  reduce  the  numbers  of  launch 
and  recovery  sites  and  equipment,  reducing  required  procurement  and  the  LCC  of  various 
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UASs  and  their  associated  support  equipment.  This  would  create  focal-point  locations  in 
operational  theaters  for  maintenance,  logistics,  launch  and  recovery  equipment,  and 
common  air  vehicle  control  stations.  However,  security  of  the  designated  locations  and 
facilities  needs  to  be  at  such  a  level  to  prevent  damage  from  enemy  attacks.  Successful 
enemy  attacks  on  a  common  basing  approach  would  be  more  detrimental  to  the  U.S. 
forces  than  comparable  attacks  on  distributed  basing. 

3.  Manpower  Requirements 

Commonality  influences  manpower  requirements  through  improvements  in 
training,  availability,  flexibility,  operator  quality,  capability,  and  productivity  for  military 
or  contractor  personnel  required  in  performing  operation  and  support  field  activities  for 
UASs.  Common  UAS  GCSs  will  require  a  reduced  number  of  UAS  training  systems  by 
enabling  flexibility  through  a  common  architecture.  A  common  architecture  allows  for  a 
single  UAS  ground  training  system  to  be  reconfigured  for  multiple  UASs.  A  reduction  in 
the  number  of  UAS  training  systems  will  reduce  manpower  requirements  for  training. 
Commonality  can  also  enable  flexible  interchange  of  personnel  at  different  sea  and  shore 
UAS  sites,  which  can  reduce  overall  manpower  requirements  and  increase  efficiency 
through  a  common  trained  force  servicing  a  number  of  UASs.  Personnel  working  on  the 
same  systems  ashore  and  at  sea  will  enable,  through  common  systems,  a  more  flexible 
force. 


“Manpower  requirements  provide  the  Navy  a  dynamic  system  for  planning, 
programming,  and  budgeting  total  force  manpower  resources  to  support  the  operating 
forces  and  the  shore  establishment  under  peacetime  and  wartime  conditions”  [DoN, 
1998].  Manpower  requirements  for  UASs  include:  1)  program  management, 
development,  engineering  and  logistics,  2)  contractor  engineering,  manufacturing, 
development,  and  support  and,  3)  military  or  contractor  operation  and  support  field 
activities. 

Operational  UAS  GCS  manpower  requirements  include  vehicle  and  sensor 
operators,  as  well  as  any  analytical  support  as  required.  AVO  staffing  will  be  dependent 
on  the  complexity  of  the  UAS  and  the  number  of  UASs  to  be  operated.  The  most 
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complex  UAS  will  need  a  highly  trained  operator  with  a  formal  flight -training  program 
[Cummings,  2008].  Sensor  operators  will  need  a  variety  of  training  to  operate  the 
different  sensor  suites  that  include  Electro-Optical/Infra-Red  (EO/IR),  radar,  and  Signal 
Intelligence  Gathering  (SIGINT).  Analytical  support  for  sensor  and  mission  products 
will  be  provided  by  outside  organizations. 

4.  Personnel  Assignments 

Commonality  influences  personnel  assignments  through  improvements  in 
training,  availability,  flexibility,  operator  quality,  capability,  and  productivity  for  military 
or  contractor  personnel  required  in  performing  operation  and  support  field  activities  for 
UASs.  Common  UAS  GCSs  and  training  systems  allow  for  a  reduction  in  the  number  of 
billets  required  for  operating  and  supporting  operational  and  training  systems.  Operators 
trained  in  a  common  UAS  will  allow  for  the  same  operators  to  utilize  the  same  equipment 
ashore  and  at  sea,  making  personnel  assignments  more  flexible  and  deereasing  the  need 
for  speeialized  assignments.  Common  support  realizes  the  same  flexibility  and  efficieney 
as  training  and  operations. 

Personnel  assignments  for  the  USN  are  managed  through  the  Navy  Personnel 
Command  (SUPERS).  Management  includes  assigning  Naval  Enlisted  Classification 
and  Naval  Officer  Classification.  Naval  classifications  “identify  a  skill,  knowledge, 
aptitude,  or  qualification... enhancing  efficient  use  of  personnel  in  distribution  and 
detailing”  [Navy  Personnel  Command,  2004].  Training  and  classification  supplements 
the  total  force  manpower  requirements,  but  are  more  specifically  targeted  to  individuals 
and  their  skill  sets. 

As  with  operator  manpower  requirements,  personnel  assignments  will  include 
both  operations  and  support  functions.  New  designators  should  be  implemented  for  the 
operations,  but  no  new  major  designators  need  to  be  required  for  support  functions. 
Cross  service  support  training  should  be  utilized  along  with  new  minor  designators  for 
support  functions.  Cross  service  training  decreases  the  manpower  and  facilities 
requirements  needed  for  training,  which  reduces  eost. 
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5.  Reliability  and  Maintainability 


Reliability  and  maintainability  (R&M)  have  well  documented  effects  on 
operational  availability  and  LCC  as  systems  reach  maturity.  Maturity  in  the  context  of 
this  discussion  is  the  point  where  no  more  or  very  little  improvement  to  R&M  should  be 
expected.  As  more  operating  hours  are  accumulated  at  a  faster  rate  due  to  more  total 
users  and  higher  utilization  of  shared  common  GCSs,  system  maturity  will  be  achieved 
sooner. 


Reliability  growth  rates  will  be  accelerated  for  common  systems  because  there 
will  be  increased  total  numbers  of  systems  fielded  and  utilization  will  be  higher  for 
shared  common  resources.  The  reliability  growth  is  achieved  through  analysis  and 
corrective  action  for  high  failure  rate  components  within  a  system  [Smith  &  Oren]. 
MIL-HDBK-189:  Reliability  Growth  Management  includes  concepts  and  principles  of 
reliability  growth,  advantages  of  managing  reliability  growth,  and  guidelines  and 
procedures  used  to  manage  reliability  growth.  It  allows  the  development  of  a  plan  that 
will  aid  in  developing  a  final  system  that  meets  requirements  and  lowers  the  LCC  of  the 
fielded  system  [DoD,  1981]. 

There  are  some  negative  effects  of  commonality  on  the  reliability  of  common 
systems.  Although  increased  commonality  will  decrease  the  number  of  components  that 
need  to  be  developed,  complexity  may  increase  if  the  components  need  to  be  more 
flexible  or  offer  additional  capabilities  [Held,  et  al.,  2008].  Factors  such  as  greater 
complexity  from  enhanced  functionality  may  lead  to  increased  failure  rates  and  reduced 
reliability  for  the  system. 

Maintainability  improvement  is  a  reduction  in  the  Mean  Time  to  Repair  (MTTR) 
and  total  Maintenance  Man-Hours  (MMH).  MTTR  and  MMH  can  be  reduced  much 
faster  for  common  systems  because  there  will  be  larger  total  numbers  of  operators  and 
more  systems  fielded  in  a  shorter  period  of  time.  This  reduction  is  mainly  accomplished 
through  maturing  of  maintenance  procedures  and  tools  through  continuous  analysis  and 
correction  of  deficiencies  documented  by  users  and  testers. 


64 


6.  Other  Logistical  Areas 


There  are  several  logistics  elements  not  previously  mentioned  that  are  affected  by 
commonality.  Facilities,  technical  data,  support  equipment,  and  supply  support  are  some 
of  the  elements  for  which  commonality  will  have  the  greatest  impact. 

One  of  the  main  affects  of  commonality  on  facilities  other  than  common  basing, 
which  has  been  previously  discussed,  is  the  opportunity  to  utilize  a  common  depot 
facility.  Common  depots  will  result  in  higher  utilization  of  facilities,  tooling,  and 
manpower  [Catington,  Knudson,  and  Yodis,  2000].  As  a  result  of  the  1991  Base 
Realignment  and  Closure  (BRAC),  the  U.S.  Army  and  USAF  were  able  to  consolidate 
depot  repairs  for  sensors,  airborne  avionics,  electronic  warfare  equipment,  and  radios. 
This  consolidation  of  depot  repair  for  common  systems  resulted  in  an  83.7  percent 
reduction  in  depot  repair  cost  for  the  affected  work  [Braman,  1997]. 

Commonality  allows  the  use  of  common  technical  publications,  including 
operator  and  maintenance  manuals.  Common  maintenance  manuals  have  advantages 
beyond  just  reduced  total  development  cost.  Technical  manual  updates  of  repurposed 
737NG  manuals  for  the  P-8A,  which  happens  periodically  for  every  platform,  will  be 
shared  with  commercial  common  737NG  fleet  operators  [Figueras,  2007]. 

If  common  systems  are  designed  with  common  interfaces,  there  is  an  opportunity 
to  procure  and  use  common  support  equipment.  A  decision  was  made  by  the  USN  to 
integrate  a  common  cockpit  into  the  MH-60S  and  MH-60R.  The  Navy  estimates  a  cost 
avoidance  of  $80  million  on  different  support  equipment  and  components  [PMA-299, 
2009]. 


A  benefit  of  having  common  supply  support  or  spare  parts  is  that  the  total  number 
of  spares  required  to  support  the  fleet  can  be  reduced.  If  different  operators  of  a  common 
system  agree  to  share  a  common  pool  of  parts,  the  total  number  of  spares  required  can  be 
reduced  significantly  [Boeing  Commercial  Airplanes,  2009].  An  example  of  benefits 
Ifom  this  type  of  cooperative  agreement  has  been  proven  beneficial  in  the  global 
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commercial  airline  business  with  the  rotable  pool  of  spare  parts  available  to  all  customers 
that  buy  the  service  [Gill,  2003]. 

There  are  at  least  two  disadvantages  of  having  common  spare  parts.  These 
disadvantages  include  finding  major  design  defects  that  exist  in  the  parts  that  may  ground 
or  significantly  restrict  an  entire  fleet,  and  obsolescence  of  common  parts,  which  could 
create  a  shortage  of  parts  within  the  supply  chain.  If  one  part  is  defective  or  becomes 
obsolete,  it  affects  every  system  in  the  inventory  that  uses  that  part. 

7.  Cost 

When  commonality  is  considered,  the  most  Ifequently  stated  benefit  is  reduced 
cost.  Costs  associated  with  commonality  not  already  discussed  in  other  sections  include 
Research  and  Development  (R&D)  cost,  procurement  cost,  and  inventory  storage  cost. 

Although  increased  commonality  will  decrease  the  number  of  components  that 
need  to  be  developed,  the  development  costs  may  increase  if  the  component  needs  to  be 
more  flexible  or  offer  additional  capabilities  [Held,  et  al,  2008].  An  example  of  this  is 
the  Single  Channel  Ground  and  Airborne  Radio  System  (SINCGARS)  that  was 
developed  in  the  1980s.  Initially,  the  USAF  and  the  U.S.  Army  were  pursuing  separate 
programs  for  an  airborne  radio,  each  with  its  own  R&D  costs.  The  initial  cost  was 
estimated  to  be  $13.7  million  for  the  U.S.  Army  and  $32  million  for  the  USAF.  The  cost 
of  adding  USAF  requirements  into  the  U.S.  Army  program  was  estimated  to  be  $16  to 
$22  million,  for  an  overall  savings  of  $10  to  $16  million  arising  from  a  reduction  in  the 
number  of  R&D  efforts,  despite  a  higher  total  overall  R&D  cost  [GAO,  1985].  If  a 
component  can  be  common  with  one  that  is  already  available,  development  costs  can  be 
very  low  or  even  zero.  The  U.S.  Marine  Corps  was  able  to  use  the  U.S.  Army’s  Shadow 
as  “a  ‘100  percent’  solution”  to  their  need  for  reconnaissance,  surveillance,  and  target 
acquisition  capabilities  without  any  service-unique  modifications  [GAO,  2009].  The  U.S. 
Marine  Corps  was  able  to  avoid  the  $180  million  development  cost  and  leveraged 
existing  production  facilities,  which  reduced  program  risk  and  cost  significantly. 
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The  relative  magnitude  of  economies  of  scale  and  purchasing  power  compared 
with  excess  capability  will  determine  the  net  impact  of  parts  costs  [Held,  et  al,  2008]. 
Common  components  offer  a  decrease  in  unit  costs  as  a  result  of  production  economies  of 
scale.  For  instance,  procurement  savings  for  the  USN  MH-60S  and  MH-60R  common 
cockpit  is  expected  to  be  $105.8  million  [PMA-299,  2009].  Greater  commonality  can 
also  allow  for  greater  purchasing  power  and  increased  competition  among  vendors  for  a 
common  part  as  a  result  of  the  higher  volume.  However,  costs  do  not  necessarily 
decrease.  Common  components  provide  excess  functionality.  For  instance,  one 
transportation  vehicle  manufacturer  decided  that  a  common  electric  cable  design  for  both 
low-end  and  high-end  items  was  too  costly  to  field  on  the  low-end  products  [Nobelius  & 
Sundgren,  2002].  An  uncommon  part  was  fielded,  resulting  in  a  nearly  50  percent 
reduction  in  parts  costs. 

Inventory  holding  cost  is  the  cost  of  carrying  one  unit  of  inventory  for  a  period  of 
time.  Holding  cost  is  the  sum  of  capital  cost,  handling  cost,  storage  cost,  obsolescence 
cost,  and  other  costs  such  as  theft  and  damage.  The  cost  of  storing  and  handling  the 
inventory  may  be  opportunity  costs  in  that  a  reduction  in  costs  would  not  be  realized 
unless  distribution  facilities  and  personnel  associated  with  handling  were  reduced.  Use 
of  common  components  among  different  systems  with  different  life  cycles  may  result  in 
decreasing  obsolescence  costs.  An  increase  in  the  number  of  common  components  is 
expected  to  decrease  the  number  of  units  held  in  inventory.  This  change  arises  from 
increased  risk  pooling  and  reduced  relative  variability  of  demands.  Net  inventory  cost, 
however,  may  either  decrease  or  increase,  depending  on  the  unit  price  effect.  Careful 
consideration  of  the  relative  magnitudes  of  these  costs  is  important  [Held,  et  al,  2008]. 

When  determining  whether  to  implement  commonality,  all  of  the  elements  must 
be  considered.  A  business  case  analysis  that  considers  all  of  the  advantages  and 
disadvantages  of  commonality  is  appropriate. 

8.  Mission  Capability 

Mission  capabilities  within  multiple  theaters  of  warfare  can  be  improved  and 
exploited  by  the  use  of  common  and  interoperable  systems  in  conjunction  with  common 
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tactics,  techniques,  proeedures  and  equipment.  If  a  eommon  and  interoperable  GCS  were 
developed,  it  must  be  able  to  support  all  missions  that  are  currently  being  conducted  in 
theater  of  operations  and  also  support  the  future  growth  of  mission  capabilities.  If  the 
GCS  did  not  support  certain  mission  threads,  stovepiped  stations  would  be  developed 
instead  and  would  defeat  the  purpose  of  commonality.  All  mission  scenarios  and 
eapabilities  of  UASs  must  be  initially  identified. 

If  a  common  GCS  is  to  be  developed  to  support  all  or  most  possible  mission 
scenarios,  a  user-needs  assessment  must  be  eondueted  to  rank  the  highest  to  lowest 
priorities  of  current  and  future  mission  threads  and  coneepts.  This  will  allow  the  systems 
engineer  to  eoneentrate  on  the  must-haves  of  system  functionality  and  deliver  to  the  user 
what  they  need  for  mission  success.  If  the  systems  engineering  principles  are  not 
eondueted  properly  when  determining  the  key  attributes  and  requirements  of  a  common 
GCS,  attempting  to  aecomplish  the  multitude  of  required  UAS  missions  and  capabilities 
described  earlier  might  not  be  aehieved. 
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IV.  PROBLEM  SCOPING 


The  research  effort  by  the  JUCCS  team  generated  information  spanning  a  wide 
breadth  of  material  associated  with  the  UAS  community.  Completing  the  efforts 
described  in  later  sections  of  the  paper  required  limiting  the  scope  of  the  focus  area  to 
identify  a  subset  of  the  problem  space  that  could  be  addressed  with  limited  time  and 
resources  of  this  project. 

The  first  scoping  effort  limited  the  problem  area  to  a  subset  of  the  elements 
influencing  commonality  and  interoperability  described  in  Chapter  III.C.  For  each  of  the 
elements,  the  team  chose  a  few  particular  aspects  of  UAS  GCS  commonality  and 
interoperability  based  on  an  understanding  of  those  areas,  quality  and  quantity  of 
available  information,  and  the  feedback  received  Ifom  stakeholders  as  to  their  interest 
areas.  The  list  below  summarizes  the  selections  made  by  the  team  for  further 
investigation  with  respect  to  elements  affecting  commonality,  they  aided  the  JUCCS  team 
in  production  of  the  functional  architecture  described  in  latter  sections  of  the  paper: 


•  Airframe  Size  and  Groupings  -  Limit  scope  to  Groups  3  and  above. 

o  Mission  and  operational  procedures  for  Group  3  and  above  UASs  share 
much  more  in  common  than  Groups  1  and  2  (small  UASs).  Eliminating 
the  smaller  systems  allows  a  more  in-depth  concentration  on  larger  UASs. 

•  Air  Vehicle  Control  versus  Mission  Specific  Payload  -  Explore  commonality 
and  interoperability  for  air  vehicle  control  functions  only. 

o  Payloads  for  UASs  are  very  specific  to  the  mission  of  the  aircraft.  These 
missions  may  vary  greatly  depending  on  the  nature  of  the  need.  Air 
vehicle  command  and  control,  however,  shares  many  common  functions 
regardless  of  the  aircraft  mission  and  payload.  Eor  this  reason,  the  scope 
will  be  limited  to  air  vehicle  control  functions  to  maximize  the  impact  of 
the  proposed  architecture. 

•  Human-Machine  Interface  -  Examine  common  HMI  for  air  vehicle  control 
functions  only. 

o  Commonality  from  a  human  machine  interface  standpoint  will  be  limited 
to  ensure  adequate  resources  for  a  thorough  study.  The  functional  focus  of 
the  proposed  architecture  will  be  limited  to  air  vehicle  control,  so  the  HMI 
considerations  will  also  be  limited  as  such. 
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•  Hardware  and  Software  -  Hardware  and  software  alloeation  is  not  required. 

o  The  study  will  limit  seope  to  funetional  level.  Sinee  no  physieal 
alloeations  will  be  determined,  differentiation  between  software  and 
hardware  funetions  is  not  requbed. 

•  Implementation  through  Retrofit  or  New  Produetion  -  Consider  implementing 
the  proposed  funetional  arehiteeture  on  new  produetion  assets  only,  retrofit 
will  not  be  explored. 

o  Limiting  seope  to  new  produetion  assets  will  allow  greater  strides  to  be 
taken  in  implementation  of  a  eornmon  arehiteeture.  Requiring  retrofit  of 
existing  systems  would  limit  the  eapability  to  implement  new  eornmon 
funetions  in  the  arehiteeture  due  to  eurrent  system  limitations. 

•  Department  of  Defense  Multiserviee  Cooperation  -  Coneentrate  on 
Department  of  Navy  systems  and  requirements. 

o  The  first  step  in  aehieving  eommonality  aeross  the  DoD  is  to  ensure  some 
eommonality  within  the  individual  serviees.  Sinee  this  objeetive  is  not 
eurrently  attained  within  the  Navy,  this  study  will  limit  the  foeus  to 
Department  ofNavy  systems. 

•  United  States  and  Allied  Cooperation  -  Limit  seope  to  U.S.  only. 

o  The  first  step  in  aehieving  eommonality  aeross  allied  forees  is  to  ensure 
eommonality  within  the  U.S.  DoD.  Sinee  this  objeetive  is  not  eurrently 
attained,  this  study  will  foeus  on  U.S.  systems  only  as  a  possible  stepping 
stone  for  future  allied  eommonality. 

The  seeond  seoping  effort  limited  the  JUCCS  benefit  analysis  to  a  subset  of  the 
areas  impacted  by  commonality  and  interoperability  deseribed  in  Chapter  III.D.  The  list 
below  summarizes  seleetions  made  by  the  JUCCS  team  for  further  investigation  with 
respeet  to  the  areas  impaeted  by  eommonality,  they  will  aid  the  JUCCS  team  in 
produetion  of  the  benefits  analysis  deseribed  in  latter  seetions  of  the  paper: 


•  Training  -  Training  is  the  primary  focus  for  the  benefits  of  the  proposed 
common  architecture. 

o  When  investigating  common  HMI  related  to  air  vehicle  control  functions, 
there  appears  to  be  a  potential  for  benefits  from  a  training  perspective. 
These  potential  benefits  arise  from  the  common  human  interface  that  may 
allow  some  consolidation  of  training  assets.  Due  to  this  potential,  training 
will  be  the  focus  for  possible  benefits  of  the  common  architecture. 

•  Basing  -  Potential  benefits  examined  only  when  related  to  training  as 
described  in  above  section. 
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•  Manpower  Requirements  -  Potential  benefits  examined  only  when  related  to 
training  as  deseribed  in  above  section. 

•  Personnel  Assignments  -  Potential  benefits  examined  only  when  related  to 
training  as  described  in  above  section. 

•  Reliability  and  Maintainability  (R&M)  -  Not  examined  further  as  part  of  this 
effort. 

•  Other  Logistical  Areas  -  Not  examined  further  as  part  of  this  effort. 

•  Cost  -  Potential  benefits  examined  only  when  related  to  training  as  described 
in  above  section. 

•  Mission  Capability  -  Not  examined  further  as  part  of  this  effort. 

The  scoping  effort  for  JUCCS  will  allow  creation  of  a  common  air  vehicle  control 
functional  architecture  for  Group  3  and  above  UASs,  which  will  facilitate  some  level  of 
interoperability  and  commonality  for  the  DoN  operational  community.  Limiting  the 
scope  as  described  led  to  concentration  on  the  current  DoN  UAS  programs  of  BAMS, 
Fire  Scout  and  STUAS.  A  benefits  analysis  performed  by  the  JUCCS  team  shows  that 
programs  implementing  the  recommended  solution  will  realize  savings  in  the  logistical 
area  of  training. 
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V.  TRAINING  AS  AN  AREA  OF  INTEREST 


As  previously  discussed,  there  are  current  DoD  programs  that  utilize  common 
training  concepts:  the  Joint  Strike  Fighter,  the  Army  One  System,  and  the  Joint  Primary 
Air  Training  System.  A  common  schoolhouse  is  one  of  the  benefits  cited  for  these  DoD 
programs  that  may  be  applicable  to  UASs.  In  order  to  achieve  the  common  schoolhouse 
training  benefit,  a  standardized  training  for  AVOs  would  need  to  be  established.  United 
States  Joint  Forces  Command  (USJFCOM)  recognized  this  and  established  a  command 
for  UASs.  This  command  enacted  policy  identifying  the  required  skill  sets  for  an  AVO. 
These  skills  sets  would  serve  as  the  basis  for  the  common  training  curriculum. 

A.  POTENTIAL  BENEFITS  FROM  UAS  AVO  COMMON  TRAINING 

As  cited  in  the  JSF  example  in  Chapter  III.D.l,  their  program  is  projected  to 
experience  70  percent  common  training  across  the  three  variants.  One  of  the  methods 
that  will  enable  common  training  is  a  common  schoolhouse,  which  is  being  set  up  at 
Eglin  Air  Force  Base.  The  DoN  is  exploring  a  common  schoolhouse  for  UAS  AVO 
training.  A  potential  benefit  from  common  UAS  AVO  training  includes  efficiencies 
gained  in  training  overhead,  such  as  configuration  control  and  update  of  course 
curriculum.  Common  training  also  ensures  standard  UAS  policies  and  procedures  are 
taught.  A  common  schoolhouse  would  provide  a  shore  station  opportunity  and  repository 
for  fleet  UAS  training  expertise  [U.S.  Fleet  Forces  Command  (USFFC),  2009].  A  study 
by  NAVAIR  Training  Systems  (PMA-205)  that  analyzed  a  common  schoolhouse  cited 
decreased  manpower  and  facilities  cost,  but  no  quantifiable  figures  were  provided  [PMA- 
205,  2009]. 

The  common  training,  especially  if  hosted  at  a  common  schoolhouse,  would 
enable  a  reduced  number  of  trainers  (both  simulators  and  Computer  Based  Training 
(CBT)),  classrooms  and  personnel  housing.  This  would  result  in  a  reduction  in 
infrastructure.  Another  benefit  of  common  training  would  be  the  reduced  manpower 
required  for  support.  The  instructors,  technicians  and  courseware  managers  would  be 
co-located.  This  reduced  infrastructure  is  due  to  training  occurring  at  one  site,  vice 
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having  training  spread  out  at  various  locations.  Finally,  training  assets  would  have  a 
higher  utilization  rate  and  gain  more  efficient  use  of  those  assets.  These  benefits  result  in 
reduced  inlfastructure,  reduced  manpower,  and  higher  asset  utilization  rate  and  would 
result  in  cost  savings  for  the  DoN.  Estimated  cost  savings  have  yet  to  be  determined. 

B.  OTHER  GOVERNMENT  EFFORTS  TOWARD  COMMON  UAS 
TRAINING 

USJFCOM  and  the  DoN  are  working  towards  establishing  policy  that  addresses 
how  UASs  will  be  utilized  in  the  future.  In  these  policy  documents,  training  has  been 
addressed  by  identifying  how  the  AVO  will  gain  qualification.  In  addition  to  policy,  the 
DoD  has  established  a  joint  command  that  will  facilitate  acquisition  of  UASs. 

1.  Joint  Unmanned  Aircraft  Systems  Center  of  Excellence 

The  Joint  Unmanned  Aircraft  Systems  (JUAS)  Center  of  Excellence  (COE)  is  a 
government  organization  consisting  of  both  military  and  government  personnel  that 
facilitates  the  development  and  integration  of  common  UAS.  Located  at  Creech  Air 
Force  Base,  Nevada,  the  JUAS  COE’s  mission  statement  is  to: 

Provide  support  to  the  Joint  Operator  and  Services  by  facilitating  the 
development  and  integration  of  common  unmanned  aircraft  system 
operating  standards,  capabilities,  concepts,  technologies,  doctrine,  tactics, 
techniques,  procedures  and  training.  JUAS  COE  leverages  existing 
COCOM  and  Service  initiatives  and  activities  to  provide  joint  integrated 
solutions  and  improved  interoperability.  [Nellis  Air  Force  Base,  2010] 

On  1  November  2007,  the  JUAS  COE  was  realigned  under  USJFCOM.  Figure  18 
depicts  the  different  organizations  responsible  to  the  Commander  USJFCOM.  The  JUAS 
COE  organization  structure  has  four  primary  divisions:  Chief  of  Staff,  Operations 
Division,  Training  Division,  and  Concepts  Division,  as  shown  in  Figure  19.  The  Chief  of 
Staff  is  adminstrative  in  nature.  The  Operations  Division  focuses  on  the  training  and 
tactics  that  are  currently  being  employed  in  combat  and  in  training  areas  throughout  the 
world.  They  assess  the  capability  gaps  on  current  unmanned  systems.  They  also 
coordinate  with  the  Federal  Aviation  Administration  (FAA)  and  foreign  airspace  centers 
and  understand  the  flight  regulations  pertaining  to  UAS  flight  across  the  globe.  The 
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Training  Division  focuses  on  the  current  and  future  methods  of  employment  and 
standardization  within  the  joint  services  and  coalition  forces.  The  Concepts  Division 
concentrates  on  future  capabilities  and  future  threats  to  the  unmanned  systems.  They 
attempt  to  project  what  type  of  unmanned  systems  will  be  employed  in  the  distant  future. 
They  also  attempt  to  roadmap  what  future  capabilities  will  be  required  and  the  platforms 
associated  with  employing  those  capabilities. 


Figure  18.  JUAS  COE  Placement  within  the  USJFCOM  Organization  Structure 

While  the  commander  of  the  JUAS  COE  is  an  0-6,  the  organization  is  placed  on  the  same  level  as  other 
organizations  that  have  1  -star  and  2-star  commanding  officers.  Figure  after  [Colt,  2009]. 
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Figure  19.  JUAS  COE  Organization  Structure 

The  JUAS  COE  Organization  is  comprised  of  four  divisions  consisting  of  Chief  of  Staff,  Operations, 
Training,  and  Concepts.  Figure  from  [Colt,  2009]. 


2.  Joint  Unmanned  Aircraft  Systems  Levels  of  Qualification 

The  JUAS  COE  has  identified  five  critical  skill  sets  and  Knowledge  Skills  and 
Abilities  (KSAs)  that  are  common  throughout  Joint  UAS  communities:  UAS  Flight  Crew 
Skills  (UASFCS),  Joint  Mission  Qualification  (JMQ),  UAS  Mission  Crew  Skills 
(UASMCS),  Unique  Service  Skills,  and  Basic  UAS  Qualifications  (BUQ)  [Chairman  of 
the  Joint  Chiefs  of  Staff  (CJCS),  2009], 

Knowledge,  Skills,  and  Abilities  (KSAs)  are  the  attributes  required  to 
perform  a  job  and  are  generally  demonstrated  through  qualifying 
experience,  education,  or  training.  Knowledge  is  a  body  of  information 
applied  directly  to  the  performance  of  a  function.  Skill  is  an  observable 
competence  to  perform  a  learned  psychomotor  act.  Ability  is  competence 
to  perform  an  observable  behavior  or  a  behavior  that  results  in  an 
observable  product.  [U.S.  Office  of  Personnel  Management  (0PM),  2010] 
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UASFCS  identify  practical  skills  to  operate  UASs  with  situational  awareness  and 
the  ability  to  execute  tasks  during  flight  operations.  The  skills  satisfy  practical  flight 
requirements  for  BUQ  Levels  I-IV  [CJCS,  2009]. 

JMQ  levels  A  to  C  provide  general  knowledge  of  the  UAS  mission  and  objective. 
This  is  critical  to  ensure  the  crews  understand  their  role  in  accomplishing  a  larger  military 
objective.  It  allows  the  operators  the  ability  to  coordinate  and  execute  in  joint  operations. 
JMQ-A  qualifications  support  unit-level  Intelligence,  Surveillance,  and  Reconnaissance 
(ISR)  in  support  of  the  Joint  Force  Commanders  (JFC).  They  also  provide  mission 
support  with  capabilities  defined  in  the  Joint  Mission  Task  Lists  (JMTL).  JMQ-B 
qualifications  support  theater-level  advanced  ISR  and  Incident  Awareness  and 
Assessment  (lAA)  mission  support  with  defined  capabilities  in  the  JMTL  of  the  JFC 
[CJCS,  2009]. 

UASMCS  are  a  group  of  skills  required  to  ensure  accomplishment  of  the  assigned 
task.  They  are  also  mission  skills  to  execute  joint  tactics,  techniques,  and  procedures  to 
meet  UAS  employment  mission  objectives.  UASMCS  satisfies  practical  mission 
requirements  for  JMQ  Levels  A-C  [CJCS,  2009]. 

Unique  Service  Skills  provide  the  UAS  crewmember  with  the  knowledge  and 
understanding  of  service  specific  missions  and  associated  requirements.  Examples 
include  maritime  environment  for  naval  UAS  and  pre-strike  reconnaissance  for  air 
interdiction  [CJCS,  2009]. 

BUQs  have  four  levels  associated  with  them  consisting  of  BUQ-I  through 
BUQ-IV.  They  focus  on  the  general  aviation  knowledge  for  successful  UAS 
employment  and  are  the  foundation  for  successful  employment  of  UAS  and  subsequent 
qualifications.  These  qualification  levels  can  be  seen  in  Figure  20.  Since  these  levels  of 
qualification  are  necessary  amongst  different  platforms  of  different  services  and 
missions,  commonality  among  the  various  services  can  be  reached.  BUQs  will  be  the 
primary  focus  of  the  JUCCS  analysis. 
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Figure  20.  UAS  Qualification  Hierarchy 

There  are  multiple  layers  of  skill  sets  that  are  essential  to  effectively  operate  a  UAS.  The  lowest  layer 
addresses  the  BUQs  that  are  further  discussed  in  this  paper.  Figure  after  [CJCS,  2009]. 

UAS  qualifications  range  Irom  a  minimum  level  of  BUQ-I  to  a  maximum  level  of 
BUQ-IV.  A  higher  BUQ  level  requires  that  each  subsequent  level  is  mastered  before  the 
next  higher  level  is  attempted. 

BUQ  Level  I  is  the  minimum  reeommended  training  level  for  all  UAS 
crewmembers.  It  possesses  the  required  aviation  knowledge  and  UAS  skills  to  fly  under 
Visual  Flight  Rules  (VFR)  in  Class  E,  G,  and  restrieted  or  combat  airspace  greater  than 
1200  feet  Above  Ground  Level  (AGL).  Explanation  of  the  different  classes  of  airspace 
can  be  found  in  Appendix  C.  BUQ-I  is  the  necessary  training  level  for  the  small  Group  1 
UASs  and  some  of  the  larger  Group  2  UASs. 

BUQ  Level  II  possesses  the  required  aviation  knowledge  and  UAS  skills  to  fly 
VER  in  Class  D,  E,  G,  and  restricted  or  eombat  airspace  greater  than  18,000  feet  Mean 
Sea  Level  (MSL).  Explanation  of  the  different  classes  of  airspace  can  be  found  in 
Appendix  C.  BUQ-II  is  the  necessary  training  level  for  some  of  Groups  2  and  3  UASs. 


78 


BUQ  Level  III  possesses  the  required  aviation  knowledge  and  UAS  skills  to  fly 
VFR  in  all  airspace  greater  than  18,000  feet  MSL.  BUQ-III  is  the  necessary  training 
level  for  some  of  Groups  3  and  4  UASs. 

BUQ  Level  IV  possesses  the  required  aviation  knowledge  and  UAS  skills  to  fly  in 
all  weather  conditions  and  classes  of  airspace  up  to  60,000  feet  MSL.  BUQ-IV  is  the 
necessary  training  level  for  some  of  Group  4  and  all  of  Group  5  UASs.  This  indicates 
that  larger,  more  complex  UASs,  such  as  BAMS,  require  the  highest  level  of  skills  that 
have  been  categorized. 

3.  Chairman  of  the  Joint  Chiefs  of  Staff  Instruction  3255.01 

The  purpose  of  the  Chairman  of  the  Joint  Chiefs  of  Staff  Instruction  (CJCSI) 
3255.01  titled  Joint  Unmanned  Aircraft  System  Minimum  Training  Standards  (JUMTS)  is 
to  identify  the  minimum  knowledge  required  for  a  UAS  crewmember  to  support  JFC 
objectives.  The  instruction  defines  the  grouping  of  various  platforms  (i.e.  Groups  1-5) 
and  the  JUMTS  skill  sets  (i.e.  BUQ,  UASFCS,  JMQ,  UASMCS,  and  Unique  Service 
Skills). 


CJCSI  3255.01  mandates  that  each  group  of  UAS  operators  obtain  a  minimum 
level  of  BUQs.  Minimum  requirements  for  the  BUQs  are  shown  in  Table  4.  The  DoD 
services  will  ensure  that  their  UAS  programs  meet  or  exceed  these  minimums  while 
fulfilling  their  responsibility  of  achieving  the  JUMTS  skill  set  definitions.  Waiver 
authority  from  not  meeting  the  stated  minimum  requirements  will  be  in  accordance  with 
DoD  service  directives.  However,  the  waiver  granting  authority  will  be  no  lower  than 
general  or  flag  officer. 

JUCCS  will  focus  on  UAS  Groups  3-5  due  to  the  complexity  and  amount  of 
funding  required  to  procure  and  sustain  each  platform,  and  train  the  required  users.  The 
JUCCS  team  will  also  focus  on  BUQs  analysis  since  they  are  the  foundation  of  all 
JUMTS  and  they  allow  for  commonality  within  training  joint  operators. 
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Table  4.  Minimum  BUQ  requirements  for  Each  UAS  Group 


This  chart  shows  the  comparison  of  UAS  Group  versus  required  BUQ  levels.  It  shows  that  larger  UASs 
require  more  BUQ  qualifications.  Figure  after  [CJCS,  2009]. 
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4.  Fleet  UAS  Platform  Wholeness  Concept  of  Operations 

The  Fleet  Unmanned  Aircraft  System  (UAS)  Platform  Wholeness  Concept  of 
Operations  (CONOPS)  was  promulgated  by  the  Commander,  U.S.  Fleet  Forces 
Command.  It  delineates  requirements  and  assigns  responsibilities  for  all  aspects  of  fleet 
UAS  support  to  achieve  platform  wholeness.  Platform  wholeness  covers  the  full  range  of 
organization,  manpower,  training  (individual,  team,  and  unit-level),  logistics, 
maintenance,  and  shore  support  needed  to  establish  BAMS,  Fire  Scout,  and  STUAS  in 
the  fleet. 

The  CONOPS  is  unclassified  but  for  official  use  only.  The  intent  is  to  present  the 
reader  with  information  needed  to  understand  how  the  fleet  will  manage  UAS  within  the 
Future  Years  Defense  Program.  This  CONOPS  summarizes  the  UAS  Type 
Commander’s  (TYCOM)  intentions  for  UAS  organizational  structure,  manpower, 
training,  and  maintenance. 

The  Fleet  Unmanned  Aircraft  System  (UAS)  Platform  Wholeness  Concept  of 
Operations  is  an  important  source  of  information  for  the  JUCCS  training  analysis  since  it 
concentrates  on  the  Group  3-5  UASs.  It  uses  the  Joint  Concept  of  Operations  for 
Unmanned  Aircraft  Systems  [USJFCOM,  2008]  and  Joint  Unmanned  Aircraft  Systems 
Minimum  Training  Standards  [CJCS,  2009]  as  the  primary  references  to  training  by 
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establishing  a  modular  training  approach.  This  approach  utilizes  several  modules  to 
form  a  course  of  instruction  that  has  been  found  to  accelerate  the  training,  reduce  costs, 
and  provide  greater  efficiencies  in  the  use  of  training  resources. 

In  the  near  term,  training  of  AVOs  and  MPOs  will  rely  on  legacy  programs  as  the 
fleet  develops  the  modular  training  approach.  Modular  training  tailors  a  UAS  training 
program  to  the  specific  requirements  determined  by  UAS  capabilities  and  mission 
requirements.  The  JUCCS  team  analyzed  the  different  BUQ  levels  (I-IV)  across  multiple 
training  regimes  by  comparing  the  number  of  KSAs  that  were  learned  in  each 
schoolhouse. 

C.  NAVAIR  AVIATION  TRAINING  SYSTEMS:  ANALYSIS  OF  BASIC  UAS 

QUALIFICATIONS 

On  15  October  2009,  NAVAIR  Training  Systems  (PMA-205)  released  a  study 
titled  Naval  Unmanned  Aircraft  Systems  (UAS)  Family  of  Systems  (FoS)  (Groups  1-5) 
Common/Core  Training  Requirements  Study  [PMA-205,  2009].  PMA-205  analyzed  the 
following  existing  training  pipelines  against  Knowledge,  Skills  and  Abilities  (KSAs)  for 
basic  qualification  requirements  for  UAS  operators: 

•  Army  Raven  Mobile  Training  Team  (MTT) 

•  Army  Shadow  training 

•  Army  Hunter  training 

•  Army  Warrior  training 

•  Air  Force  UAS  Operator  training 

As  a  result,  the  spectrum  of  existing  GCS  architectures  can  be  compared  and  analyzed  for 
commonality  traits  with  respect  to  training.  This  analysis  can  help  determine  whether  the 
current  training  strategies  already  incorporate  some  commonality.  A  summary  of  the 
PMA-205  analysis  has  been  broken  down  into  qualification  levels,  and  can  be  found  in 
the  charts  on  the  following  pages. 
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1. 


BUQ-I  Analysis 


BUQ  Level  I  is  the  minimum  reeommended  training  level  for  all  UAS 
crewmembers.  The  results  of  the  analysis  in  Figure  21  show  that  the  Army  Hunter  UAS 
trains  to  the  most  KSAs  across  all  other  the  platforms  and  training  pipelines.  Since  it 
meets  the  majority  of  the  required  KSAs,  the  Army  Hunter  UAS  curriculum  has  the  most 
potential  to  achieve  a  commonality  requirement  for  a  joint  UAS  training  site  for  BUQ-I. 
The  Army  Raven  MTT  trains  to  the  least  of  the  KSAs  when  compared  to  other  specific 
UAS  platforms. 


BUQ  I  Comparison 


Training  Specialties 


Figure  21.  BUQ-I  KSA  Analysis  across  Various  UAS  Training  Pipelines 

Not  a  single  current  training  program  examined  provides  all  KSAs  required  for  a  Level  I  BUQ 
certification.  Figure  after  [PMA-205,  2009]. 


2.  BU Q-II  Analysis 

The  results  of  the  analysis  in  Figure  22  show  that  the  USAF  UAS  Operator 
pipeline  trains  to  all  of  the  KSAs  analyzed.  Since  it  meets  all  of  the  required  KSAs,  the 
USAF  UAS  Operator  curriculum  has  the  most  potential  to  achieve  a  commonality 
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requirement  for  a  joint  UAS  training  eurrieulum  for  BUQ-II.  The  Army  Raven  MTT 
eontinues  to  train  to  the  least  of  the  KSAs  when  eompared  to  other  speeifie  UAS 
platforms. 


BUQ  II  Comparison 


Training  Specialties 


Figure  22.  BUQ-II  KSA  Analysis  across  Various  UAS  Training  Pipelines 

The  USAF  UAS  Operator  training  provides  all  KSAs  required  for  a  Level  II  BUQ  certification.  Figure 

after  [PMA-205,  2009]. 


3.  BU Q-III  Analysis 

BUQ  Level  III  possesses  the  required  aviation  knowledge  and  UAS  skills  to  fly 
VFR  in  all  airspaee  greater  than  18,000  feet  MSL.  The  results  of  the  analysis  in  Figure 
23  show  that  the  USAF  UAS  Operator  pipeline  trains  to  all  of  the  KSAs  analyzed.  Sinee 
it  meets  all  of  the  required  KSAs,  the  USAF  UAS  Operator  eurrieulum  has  the  most 
potential  to  aehieve  a  eommonality  requirement  for  a  joint  UAS  training  eurrieulum  for 
BUQ-III.  The  Army  Raven  MTT  trains  to  the  least  of  the  KSAs  when  eompared  to  other 
speeifie  UAS  platforms. 
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BUQ  III  Comparison 


Training  Specialties 


Figure  23.  BUQ-III KSA  Analysis  across  Various  UAS  Training  Pipelines 

The  USAF  UAS  Operator  training  provides  all  KSAs  required  for  a  Level  III  BUQ  certification.  Figure 

after  [PMA-205,  2009]. 


4.  BUQ- IV  Analysis 

BUQ  Level  IV  possesses  the  required  aviation  knowledge  and  UAS  skills  to  fly  in 
all  weather  eonditions  and  elasses  of  airspaee  up  to  60,000  feet  MSL.  The  results  of  the 
analysis  in  Figure  24  show  that  the  USAF  UAS  Operator  pipeline  trains  to  all  of  the 
KSAs  analyzed.  Since  it  meets  all  of  the  required  KSAs,  the  USAF  UAS  Operator 
curriculum  has  the  most  potential  to  achieve  a  commonality  requirement  for  a  joint  UAS 
training  curriculum  for  BUQ-IV.  The  Army  Raven  MTT  continues  to  train  to  the  least 
KSAs  when  compared  to  other  speciflc  UAS  platforms. 
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BUQ  IV  Comparison 


Training  Specialties 


Figure  24.  BUQ-IV  KSA  Analysis  across  Various  UAS  Training  Pipelines 

The  USAF  UAS  Operator  training  provides  all  KSAs  required  for  a  Level  IV  BUQ  certification.  Figure 

after  [PMA-205,  2009]. 


5.  BUQ-I  through  IV  Combined  Analysis 

The  results  of  the  analysis  in  Figure  25  show  that  the  USAF  UAS  Operator 
pipeline  trains  to  the  most  KSAs  across  all  other  platforms  and  training  pipelines  when 
BUQ  Levels  I-IV  are  combined.  Since  it  meets  the  majority  of  the  required  KSAs,  the 
USAF  UAS  Operator  curriculum  has  the  most  potential  to  achieve  a  commonality 
requirement  for  a  common  joint  UAS  training  site  that  trains  to  all  BUQ  KSAs.  The 
Army  Raven  MTT  trains  to  the  least  KSAs  when  compared  to  other  specific  UAS 
platforms. 
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Figure  25.  BUQ-I  through  IV  Combined  KSA  Analysis  across  Various  UAS  Training  Pipelines 

The  USAF  UAS  Operator  training  comes  closest  to  meeting  all  required  KSAsfor  gaining  BUQ  Levels  1  -IV 

certification.  Figure  after  [PMA-205,  2009]. 

The  intent  of  reviewing  the  PMA-205  analysis  is  to  determine  whether  or  not 
eurrent  UAS  training  systems  aetually  teaeh  all  of  the  UAS  training  requirements.  A 
look  at  these  various  programs  shows  that  none  of  them  train  to  all  of  the  KSAs  required 
for  BUQ  Levels  I-IV.  Additionally,  the  study  reveals  that  the  training  strategies  do  not 
share  eommon  goals,  sinee  they  all  teaeh  to  different  numbers  of  KSAs  for  eaeh  BUQ 
level.  This  implies  that  there  is  little  eommonality  between  the  eurrent  training  systems. 

These  revelations  lead  to  the  following  questions: 

•  If  a  eommon  GCS  arehiteeture  were  ereated,  would  it  allow  greater 
efficiencies  across  the  UAS  training  pipelines? 

•  What  requirements  are  necessary  for  this  type  of  common  GCS? 

•  To  meet  these  requirements,  what  architectural  characteristics  need  to  be 
developed? 

The  first  step  in  answering  these  questions  is  to  derive  some  requirements  for  a  common 
GCS  that  relate  back  to  the  KSAs  for  the  BUQ  levels  described  above. 
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VI.  REQUIREMENTS  ANALYSIS  EOR  A  COMMON  GCS 


Limiting  the  scope  of  the  project  led  to  concentration  on  the  current  DoN  UAS 
programs  of  BAMS,  Fire  Scout  and  STUAS.  A  requirements  analysis  of  these  UAS 
programs  was  conducted  as  part  of  the  systems  engineering  process  to  understand  the 
requirements  of  UASs  and  to  establish  a  foundation  from  which  to  proceed.  This 
analysis  included  programs  of  record  which  were  in  some  stage  of  acquisition  by  the 
DoN  as  of  fiscal  year  2010.  Additionally,  further  review  of  the  source  documentation  led 
to  the  development  of  a  set  of  requirements  which  were  used  for  the  basis  of  the  proposed 
common  GCS  architecture  discussed  in  Chapter  VII. 

A.  OVERVIEW  OF  CURRENT  NAVY  UAS  REQUIREMENTS 

A  requirements  analysis  of  the  three  UAS  programs  of  interest  began  with  an 
evaluation  of  their  approved  Capability  Development  Document  (CDD)  or  Capability 
Production  Document  (CPD)  and  system  specification.  Exploration  of  each  document 
revealed  similarities  and  differences  in  the  areas  of  primary  interest  to  the  JUCCS  team: 
training,  interoperability,  and  requirements  explicitly  detailing  commonality.  Also 
examined  from  each  program’s  requirements  documentation  were  the  Key  Performance 
Parameters  (KPPs)  and  Key  System  Attributes.  The  following  sections  provide  these 
analyses. 

1.  Key  Performance  Parameters 

KPPs  are  those  system  attributes  that  are  considered  essential  for  successful 
mission  accomplishment.  Each  acquisition  program  generally  contains  a  limited  number 
of  KPPs  (usually  eight  or  fewer)  that  capture  those  parameters  needed  to  reach  the  overall 
desired  capabilities  for  the  system.  Eailure  to  meet  a  KPP  threshold  can  be  cause  for  the 
system  selection  to  be  reevaluated,  the  program  to  be  reassessed  or  terminated,  or  the 
content  of  production  increments  modified  [USD(AT&E),  2008]. 

Table  5  displays  the  KPPs  for  BAMS,  Eire  Scout,  and  STUAS. 
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Table  5.  Comparison  of  DoN  UAS  Key  Performance  Parameters 

This  list  shows  those  requirements  considered  most  important  to  determine  the  success  of  each  program.  None  of  these  requirements  is  levied  on  the  GCS,  nor  is 

there  any  application  of  a  requirement  across  all  three  programs  with  the  exception  of  the  Net  Ready  KPP. 


It  should  be  noted  that  the  only  KPP  shared  between  all  three  programs  is  the  Net  Ready 
KPP  mandated  for  all  aequisition  programs.  Aside  from  this  requirement  the  three 
programs  have  established  their  own  unique  eriteria  for  essential  system  eapabilities. 

With  the  majority  of  KPPs  involving  the  air  vehiele,  it  is  apparent  that  the  GCS  is 
not  the  focus  of  key  requirements  for  existing  programs.  Training  is  not  shown  as  a  KPP 
in  any  of  these  programs.  Commonality  is  also  not  a  focus  of  required  capabilities  for 
any  of  these  systems. 

2.  Key  System  Attributes 

Key  System  Attributes  are  those  system  attributes  considered  most  critical  or 
essential  for  an  effective  military  capability  but  not  selected  as  KPPs.  Key  System 
Attributes  provide  decision  makers  with  an  additional  level  of  capability  prioritization 
below  the  KPP  but  with  senior  sponsor  leadership  control.  Key  System  Attributes  and 
other  performance  attributes  will  be  based  on  analysis  of  the  required  capability 
[USD(AT&L),  2008]. 

BAMS  has  Key  System  Attributes  that  address  the  deployability  of  the  air 
vehicle,  mission  planning,  flight,  on  station  capabilities,  and  sensor  capabilities.  None  of 
the  Key  System  Attributes  focus  on  the  GCS  capabilities.  Other  requirements  are  levied 
on  the  GCS  that  include  the  ability  to  control  multiple  air  vehicles  (three  as  a  threshold 
and  twelve  as  an  objective).  The  GCS  is  required  to  be  capable  of  transferring  control  of 
an  air  vehicle  from  one  BAMS  GCS  to  another  BAMS  GCS  [PMA-263,  2007].  There 
are  no  requirements  to  be  interoperable  or  common  with  other  platform  GCSs. 

Similarly,  the  Key  System  Attributes  for  the  Fire  Scout  program  do  not  focus  on 
the  GCS  or  on  training.  The  Fire  Scout  program  does  require  that  the  GCS  be  capable  of 
mission  planning,  air  vehicle  control,  receipt  of  data  and  dissemination  of  data  [PMA- 
263,  2008].  The  GCS  shall  be  able  to  control  two  Fire  Scout  aircraft  simultaneously  and 
transfer  control  of  an  aircraft  from  one  GCS  to  another  [Northrop  Grumman  Systems 
Corporation,  2007].  Again,  this  transfer  is  only  required  between  Fire  Scout  GCSs. 
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The  STUAS  Performance  Based  Specification  (PBS)  contains  three  pages  of  Key 
System  Attributes.  System  reliability,  sensor  performance  and  affordability  are  the 
subjects  of  Key  System  Attributes  [PMA-263,  2009].  Once  again,  training  and 
commonality  are  not  listed  in  any  of  the  Key  System  Attributes. 

3.  CDD,  CPD  and  System  Specification  Comparison 

For  each  of  the  programs  examined,  the  CDD,  CPD  and  system  specification  was 
found  and  then  compared  and  contrasted  with  one  another.  Some  surprising 
commonality  in  requirements  language  was  discovered  and  can  be  seen  in  Table  6.  The 
extent  of  the  similarity  suggested  that  each  program  copied  wording  from  the  previous 
program.  Yet,  interestingly,  there  was  no  requirement  for  each  individual  program  to 
specifically  leverage  off  the  other  system’s  development  or  to  gain  in  any  way  from 
previous  development.  Each  training  system  separately  developed  its  own  training 
support  system. 
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Table  6.  CDD  and  CPD  Wording  Related  to  Training  for  DoN  UASs 


This  table  compares  some  of  the  similar  requirements  from  BAMS,  Fire  Scout  and  STUAS  with  respect  to 
training.  Note  the  similarities  in  wording  across  the  various  systems. 


BAMS 

Fire  Scout  (VTUAV) 

STUAS 

Training  shall  be  available  at 
any  operating  location  and 
will  be  sustainable  over  the 
life  of  the  system. 

Training  will  be  available  at  any 
operating  location,  through  the 
use  of  training  devices  and  a 
distributed  learning  system,  and 
will  be  sustainable  over  the  life 
of  the  system. 

Training  will  be  available  at 
any  operating  location,  through 
the  use  of  training  devices  and 
a  distributed  learning  system, 
and  will  be  sustainable  over  the 
life  of  the  system. 

Appropriate  human 
performance  metrics, 
methodologies  and 
verification  procedures  will  be 
part  of  the  BAMS  UAS 
training  system. 

Appropriate  human  performance 
metrics,  methodologies  and 
verification  procedures  will  be 
part  of  the  VTUAV  System 
training  system. 

Human  performance 
requirements  will  be 
considered  in  the  design  of  the 
Tier  II/STUAS  from  the 
earliest  stages  of  acquisition 
and  throughout  the  life  cycle 
engineering  activities. 

The  BAMS  UAS  training 
system  should  be  supportable 
by  the  Navy  personnel 
distribution  system  and  will 
ensure  qualified  personnel 
report  to  assume  assigned 
duties  within  a  minimal 
turnover  period. 

The  VTUAV  System  training 
system  will  be  supportable  by 
the  Navy  personnel  distribution 
system  and  will  ensure  qualified 
personnel  report  to  assume 
assigned  duties  within  a  minimal 
turnover  period. 

The  Navy’s  STUAS  training 
system  will  be  supportable  by 
the  Navy  personnel  distribution 
system  and  will  ensure 
qualified  personnel  report  to 
assume  assigned  duties  with  a 
minimal  turnover  period. 

In  Table  7,  it  is  apparent  that  each  program  looked  to  have  embedded  training 
capability  so  that  training  could  leverage  off  the  operational  system.  Although  this  may 
help  a  specific  program’s  ability  to  reduce  its  own  training  related  expenses,  it  does 
nothing  to  assist  the  other  program’s  efforts.  Likewise,  there  appears  to  be  foresight  in 
the  need  to  leverage  off  the  operational  system  software  development,  however  nothing  is 
captured  in  the  requirements  to  leverage  off  software  development  completed  by  other 
programs.  Each  program  is  on  their  own  in  developing  separate  hardware  and  software 
solutions,  even  though  they  strive  for  similar  goals. 
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Table  7.  System  Specification  Wording  Related  to  Training  for  DoN  UASs 


This  table  shows  some  of  the  system  specification  wording  across  the  various  programs.  Note  that  the 
programs  are  all  discussing  embedded  capabilities  for  usage  in  training,  but  none  are  requiring 

commonality  between  the  other  platforms. 


BAMS 

Fire  Scout  (VTUAV) 

STUAS 

The  UAS  Training  System 
(TS)  will  be  an  integrated 
system  which  will  use  the 
baseline  developed  Top  Level 
Operator  Mission  Task 

Analysis  and  the  Contractor 
and  Government  performed 
Instructional  Systems 
Development  (ISD)  Front  End 
Analysis  (FEA)  processes  to 
determine  specific  training 
requirements. 

The  VTUAV  CS  shall  be 
compatible  with  embedded 
and  add-on  interactive 
training. 

As  an  integral  portion  of  the  GS, 
the  MTD  provides  the  ability  to 
execute  training  through  a  safe, 
interlocked  interface  which 
physically  isolates  a  GS 
workstation  from  communicating 
with  any  AV,  while  still  using  the 
GCS  operational  software  to 
provide  proficiency,  emergency 
procedure  and  mission  rehearsal 
training  to  the  crew. 

The  MOB  MCS  shall  include 
an  integrated,  full-mission 
training  capability. 

The  VTUAV  system  shall 
provide  for  training  of 
organizational  level 
operator  and  maintenance 
personnel. 

The  integrated  GCS  and  UAS 

MTD  assembly  shall  provide  the 
sufficient  and  necessary 
capabilities  to  complete 
emergency  procedures  training, 
proficiency  training,  and  mission 
rehearsal  for  all  users. 

The  MOB  MCS  shall  include 
an  integrated,  full-mission 
training  capability. 

All  electronic  media 
training  materials  shall 
function  stand-alone  via 

CD  ROM,  over  the  web, 
via  Navy  E-Leaming/Navy 
Knowledge  On-Line,  and 
from  Navy-Marine  Corps 
Internet  (NMCI) 
computers. 

The  software  in  GCS  used  during 
flight  operations  shall  be  the 
same  software  when  interfacing 
with  the  MTD. 
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4.  Commonality  as  a  New  Requirement 


As  evidenced  through  the  requirements  analysis  of  the  BAMS,  Fire  Scout,  and 
STUAS  programs,  each  has  taken  a  program-centric  approach  with  little  or  no 
consideration  to  commonality.  Moreover,  until  the  release  of  the  February  2009  ADM 
that  directs  UAS  GCS  commonality,  there  has  been  no  requirement  for  programs  to  be 
common.  The  origin  of  this  requirements  gap  has  been  illustrated  chronologically  per 
Figure  26.  The  following  section  addresses  this  requirements  gap,  and  attempts  to  extract 
requirements  for  a  proposed  common  GCS. 


2007 

2008 

2009 

J  1  F  M  a|  M  J  J  1  A  S|  0|  N  D 

J  1  F  M  a|  m|  J  J  1  A  S|  0|  N  D 

J  1  f|  M  a|  m|  J  1  J  A  S  1  0  N  D 

t  t  t  t  t  t  It 


Fire  Scout  BAMS  BAMS  Fire  STUAS  USD  UAS  JUAS 

System  CDD  CONOPS  Scout  CDD  (AT&L)  Wholeness  CONOPS 

Spec  CDD  ADM  CONOPS 


Figure  26.  Timeline  Showing  Requirements  Development  for  DoN  UASs 


The  timeline  shows  the  chronological  development  of  the  DoN  UAS  requirements  documents.  Note  that  all 
documents  with  commonality  philosophies  come  after  the  UAS  specifications  have  already  been  developed. 
This  condition  has  led  to  the  current  lack  of  commonality  among  DoN  systems. 


B.  NECESSARY  REQUIREMENTS  FOR  A  COMMON  GCS 

An  objective  of  this  project  is  to  determine  what  a  common  GCS  architecture 
would  look  like.  One  of  the  first  steps  toward  this  goal  is  to  extract  some  requirements 
for  a  common  GCS. 

1.  Requirements  Facilitating  Common  AVO  Training 

Following  the  2009  ADM,  the  Fleet  UAS  Platform  Wholeness  CONOPS  [USFFC, 
2009]  was  published  providing  guidance  for  achieving  commonality  among  UASs.  This 
CONOPS  was  used  to  extract  the  first  requirement  for  the  proposed  common  UAS  GCS: 
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•  The  Ground  Control  Station  (GCS)  shall  enable  Air  Vehiele  Operator  (AVO) 
training  commonality  across  multiple  Unmanned  Aircraft  System  (UAS) 
platforms. 

For  AVO  training  commonality,  programs  are  directed  to  ensure  compliance  with  the 
BUQs  defined  in  CJCSI  3255.01  Joint  Unmanned  Aircraft  Systems  Minimum  Training 
Standards  [CJCS,  2009].  As  identified  by  the  expanded  JUCCS  analysis,  all  but  seven  of 
these  BUQs  can  be  accommodated  through  implementation  of  a  common  GCS.  By 
requiring  GCS  commonality,  common  AVO  training  can  be  achieved.  Therefore,  the 
following  specific  characteristics  have  been  extracted  for  the  GCS  in  order  to  facilitate 
the  common  AVO  training  concept: 

•  The  Ground  Control  Station  (GCS)  shall  have  a  common  Human-Machine 
Interface  (HMI)  for  Air  Vehicle  Operator  (AVO)  functions. 

In  order  to  achieve  a  common  GCS  and  common  AVO  training,  a  common  HMI  is 
necessary  for  AVO  functions. 

•  The  Ground  Control  Station  (GCS)  shall  allow  for  directed  vice  controlled  air 
vehicle  operation. 

Fire  Scout  has  set  requirements  for  a  point-and-click  route  planning  to  include  terrain 
avoidance  warning,  fuel  calculations,  and  radar  terrain  masking.  The  necessity  for  a 
point-and-click  route  is  considered  to  be  the  directed  as  opposed  to  the  controlled  UAS 
philosophy. 

•  The  Ground  Control  Station  (GCS)  shall  allow  for  separate  Human-Machine 
Interfaces  (HMI)  for  payload  and  air  vehicle  control. 

Fire  Scout  has  called  for  a  GCS  “consisting  of  an  AVO  and  an  MPO  work  station.”  It 
goes  on  to  state  that  “crews  will  consist  of  an  AVO  and  an  MPO”  [PMA-205,  2008].  The 
separation  of  these  functions  requires  separation  of  the  HMI  enabling  performance  of  the 
functions. 
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•  The  Ground  Control  Station  (GCS)  shall  have  a  common  mission  planning 
system. 

Fire  Scout  requires  that  the  GCS  will  be  used  to  plan  and  monitor  flights  for  performance 
of  assigned  missions  [PMA-205,  2008].  A  common  mission  planning  system  is 
necessary  to  enable  a  common  GCS  with  common  AVO  training  functions. 

2.  Additional  Requirements  for  a  Common  GCS 

Up  to  this  point,  evaluation  of  UAS  GCSs  has  focused  on  AVO  training.  A 
common  GCS  would  need  requirements  beyond  the  AVO  training.  To  achieve  greater 
potential  benefits  and  to  enable  a  common  GCS,  the  following  requirements  are  proposed 
by  the  JUCCS  team  in  addition  to  aforementioned  common  AVO  training: 

•  The  Ground  Control  Station  (GCS)  shall  enable  interoperability  between 
multiple  Unmanned  Aircraft  Systems  (UASs). 

STANAG  4586,  as  discussed  previously,  details  interoperability  standard  for  UASs  and 
GCSs.  All  three  programs  evaluated  in  this  report  require  compliance  with  STANAG 
4586.  It  is  therefore  reasonable  to  expect  all  future  UAS  programs  to  require 
interoperability. 

•  The  Ground  Control  Station  (GCS)  shall  enable  common  communications  and 
data  link  management  between  multiple  Unmanned  Aircraft  Systems  (UASs). 

The  OSD  Roadmap  indicates  that  “all  UAS  systems  will  have  the  ability  to  communicate 
and  can  therefore  act  as  relay  nodes  for  C2  communications”  [OSD,  2007].  In  order  to 
achieve  this,  it  is  essential  for  common  communications  and  data  link  management. 

•  The  Ground  Control  Station  (GCS)  shall  utilize  a  common  data  format  to 
enable  communication  between  multiple  manned  and  unmanned  systems. 

USD(AT&L)  calls  for  accelerating  the  fielding  of  CDL  compliant  communications 
systems.  The  OSD  Roadmap  recommends  “greater  interoperability  among  system 
controls,  communications,  data  products,  data  links,  and  payloads/mission  equipment 
packages  on  unmanned  systems”  [OSD,  2007].  A  common  data  format  will  enable 
increased  interoperability  and  sharing  of  data  collected  by  the  air  vehicle. 
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•  The  Ground  Control  Station  (GCS)  systems  software  and  arehiteeture  shall  be 
modular  and  scalable. 

USD(AT&L)  has  directed  the  services  “to  develop  and  demonstrate  a  common,  open,  and 
scalable  UAS  architecture  supporting  Groups  2-5”  [USD(AT&L),  2009].  The  use  of 
modular  and  scalable  systems  software  and  architecture  will  facilitate  interoperability.  It 
will  also  enable  the  incorporation  of  future  technologies. 

•  The  Ground  Control  Station  (GCS)  shall  enable  a  common  approach  to 
simplify  support  and  maintenance  across  multiple  Unmanned  Aircraft  System 
(UAS)  platforms. 

The  UAS  Wholeness  CONOPS  requires  that  UASs  shall  use  common  approaches  to 
simplify  UAS  support  and  maintenance. 

•  The  Ground  Control  Station  (GCS)  shall  enable  a  common  approach  to  reduce 
the  manpower  requirements  across  multiple  Unmanned  Aircraft  System 
(UAS)  platforms. 

The  UAS  Wholeness  CONOPS  requires  that  UASs  shall  use  common  approaches  to  UAS 
manpower  support. 

•  The  Ground  Control  Station  (GCS)  shall  enable  a  common  approach  to 
minimize  Unmanned  Aircraft  System  (UAS)  basing. 

The  UAS  Wholeness  CONOPS  requires  that  UASs  shall  use  common  approaches  to  UAS 
manpower  basing. 

These  requirements  are  those  considered  vital  to  a  proposed  common  GCS.  The 
first  set  of  requirements  will  facilitate  the  common  training  while  the  others  are  a  mixture 
of  miscellaneous  requirements  that  aid  in  the  successful  creation  of  a  common  GCS.  The 
needs  discussed  above  have  been  compiled  into  a  comprehensive  list  in  Table  8. 
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Table  8.  Necessary  Requirements  for  a  Common  GCS 

This  table  summarizes  the  requirements  necessary  for  a  common  GCS.  The  table  includes  specific  wording 
for  the  requirements  along  with  the  source  of  the  requirement  derivation. 


JUCCS  Proposed 
Common  Architecture 
Requirement 

Derived  from 

Document(s) 

CONOP/Requirement 

1 .  The  Ground  Control 
Station  (GCS)  shall 
enable  Air  Vehiele 
Operator  (AVO) 
training  eommonality 
aeross  multiple 
Unmanned  Airerafl 
System  (UAS) 
platforms. 

•  UAS  Platform  Wholeness 
CONOPS 

•  CJCSI  3255.01 

•  USD(AT&L)  ADM 

•  Field  UASs  with  eommon  AVO  training 
standards. 

•  Inerease  training  effieieneies  and  deerease 
training  time. 

•  Reduee  training  requirements. 

2.  The  Ground  Control 
Station  (GCS)  shall 
have  a  eommon 
Human-Maehine 
Interfaee  (HMI)  for 

Air  Vehiele  Operator 
(AVO)  flmetions. 

•  Fire  Seoul  System 
Speeifieation 

•  STUAS  CDD  and  PBS 

•  BAMS  PBS 

•  UAS  shall  use  a  STANAG  4586  eompliant 
GCS. 

•  Human  maehine  interfaees  shall  eomply  with 
MIL-STD-1472. 

3.  The  Ground  Control 
Station  (GCS)  shall 
allow  for  direeted 
viee  eontrolled  air 
vehiele  operation. 

•  Fire  Seoul  System 
Speeifieation 

•  STUAS  PBS 

•  The  GCS  HMI  shall  be  a  direeted  type 
interfaee. 

4.  The  Ground  Control 
Station  (GCS)  shall 
allow  for  separate 
Human-Maehine 
Interfaees  (HMI)  for 
payload  and  air 
vehiele  eontrol. 

•  Fire  Seoul  NTSP 

•  UAS  Platform  Wholeness 
CONOPS 

•  Operators  shall  operate  a  single  GCS 
eonsisting  of  an  AVO  and  an  MPO  work 
station. 

•  Crews  will  eonsist  of  an  AVO  and  an  MPO. 
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Table  8.  Necessary  Requirements  for  a  Common  GCS  (continued) 


JUCCS  Proposed 
Common  Architecture 
Requirement 

Derived  from 

Document(s) 

CONOP/Requirement 

5.  The  Ground  Control 
Station  (GCS)  shall 
have  a  common 
mission  planning 
system. 

•  Fire  Scout  NTSP 

•  JUAS  CONOPS 

•  GCS  will  be  used  to  plan  and  monitor  flights 
for  performance  of  assigned  missions 

•  Current  doctrine  provides  for  parallel 
planning  processes  for  ISR/RSTA  and  Joint 
Fires. 

•  UAS  planning  and  employment 
considerations  will  be  examined 

6.  The  Ground  Control 
Station  (GCS)  shall 
enable 

interoperability 
between  multiple 
Unmanned  Aircraft 
Systems  (UASs). 

•  STUAS  CDD 

•  UAS  Platform  Wholeness 
CONOPS 

•  Fire  Scout  System 
Specification 

•  STUAS  PBS 

•  USD(AT&L)  ADM 

•  GCS  shall  be  compliant  with  STANAG  4586 
for  system  interoperability. 

•  GCS  shall  be  interoperable  with  other  UAS 
operating  and  control  systems. 

•  GCS  shall  use  a  standardized  user  interface 
across  all  configurations. 

•  Improve  interoperability. 

7.  The  Ground  Control 
Station  (GCS)  shall 
enable  common 
communications  and 
data  link  management 
between  multiple 
Unmanned  Aircraft 
Systems  (UASs). 

•  Fire  Scout  System 
Specification 

•  Fire  Scout  NTSP 

•  JUAS  CONOPS 

•  USD(AT&L)  ADM 

•  OSD  Roadmap 

•  GCS  shall  be  capable  of  interfacing  with 
other  fielded  UASs  via  common  C4I  systems. 

•  GCS  shall  have  the  capability  for  external  and 
internal  voice  communications  with  other 
manned  and  unmanned  systems. 

•  A  suite  of  communications  systems  shall 
include  the  common  data  link  to  provide 
continuous  contact  between  system  operators 
and  the  UAV 

•  Field  common  data  link  compliant 
communications  system  leveraging  to  the 
greatest  extent  possible  current  and  future 
interoperability  profiles. 
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Table  8.  Necessary  Requirements  for  a  Common  GCS  (continued) 


JUCCS  Proposed 
Common  Architecture 
Requirement 

Derived  from 

Document(s) 

CONOP/Requirement 

8.  The  Ground  Control 
Station  (GCS)  shall 
utilize  a  common  data 
format  to  enable 
communication 
between  multiple 
manned  and 
unmanned  systems. 

•  STUAS  CDD 

•  Fire  Scout  System 
Specification 

•  GCS  shall  use  standardized  data  and  controls. 

•  All  communications  systems  shall  meet  DoD, 
U.S.  and  International  frequency  spectrum 
management  policies  and  regulations. 

•  Improve  data  access. 

9.  The  Ground  Control 
Station  (GCS) 
systems  software  and 
architecture  shall  be 
modular  and  scalable. 

•  STUAS  CDD 

•  Fire  Scout  NTSP 

•  UAS  Platform  Wholeness 
CONOPS 

•  USD(AT&L)  ADM 

•  UAS  shall  implement  a  modular  open 
systems  architecture. 

•  AV  and  GCS  software  shall  be  modular  and 
scalable. 

•  System  shall  support  existing  Navy  system 
external  interfaces  and  implement  an  open 
systems  architecture  standard. 

•  Adopt  a  common  GCS  architecture  that  is 
open  and  allows  for  modular  functionality. 

•  Develop  and  demonstrate  a  common,  open, 
and  scalable  UAS  architecture  supporting 
Groups  2-5. 

10.  The  Ground  Control 
Station  (GCS)  shall 
enable  a  common 
approach  to  simplify 
support  and 
maintenance  across 
multiple  Unmanned 
Aircraft  System 
(UAS)  platforms. 

•  UAS  Platform  Wholeness 
CONOPS 

•  UASs  shall  use  common  approaches  to 
simplify  UAS  support  and  maintenance. 
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Table  8.  Necessary  Requirements  for  a  Common  GCS  (continued) 


JUCCS  Proposed 
Common  Architecture 

Derived  from 

Requirement 

Document(s) 

CONOP/Requirement 

1 1 .  The  Ground  Control 

•  UAS  Platform  Wholeness 

•  UAS  shall  use  common  approaches  to  UAS 

Station  (GCS)  shall 
enable  a  common 

CONOPS 

manpower  support. 

approach  to  reduce 
the  manpower 

•  BAMS  CDD 

•  The  workload  associated  with  training  must 
be  analyzed  and  accounted  for  in  the 

requirements  across 
multiple  Unmanned 

•  Fire  Scout  CPD 

manpower  requirements. 

Aircraft  System 
(UAS)  platforms. 

•  USD(AT&L)  ADM 

•  Increase  pool  of  UAS  pilots/operators. 

12.  The  Ground  Control 

•  UAS  Platform  Wholeness 

•  UAS  shall  use  common  approaches  to  UAS 

Station  (GCS)  shall 
enable  a  common 
approach  to  minimize 
Unmanned  Aircraft 
System  (UAS) 
basing. 

CONOPS 

manpower  basing. 
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VII.  JUCCS  PROPOSED  COMMON  GCS  ARCHITECTURE 

The  common  architecture  proposed  by  the  JUCCS  team  was  developed  using  the 
requirements  derived  from  the  analysis  in  the  previous  section.  The  architecture 
development  focused  on  the  air  vehicle  control  functions  with  a  modular,  scalable 
construct  that  would  enable  a  common  GCS  across  multiple  platforms.  This  approach 
was  influenced  by  the  requirements  for  commonality  as  directed  in  the  ADM.  The 
architecture  development  approach  included  research  and  analysis  of  current  relevant 
architectures  and  architecture  development  strategies,  development  of  an  external 
systems  diagram,  and  development  of  a  functional  architecture  [Dam,  2006].  The 
architecture  focused  on  the  human-machine  interface  of  the  air  vehicle  control  functions. 

A.  JUCCS  ARCHITECTURAL  ELEMENTS 

1.  Inspiration  for  the  Architectural  Structure 

The  JUCCS  architecture  is  based  on  the  ability  to  be  both  modular  and  scalable  in 
accordance  with  the  requirements  derived  in  Chapter  VI. B.  The  concept  will  be  limited 
to  a  functional  allocation  to  allow  for  a  variety  of  physical  architectures.  This  allows 
different  number  of  crew  positions  based  on  mission  requirements  and  GCS  operating 
locations.  A  two  person  crew  might  be  needed  for  a  smaller  UAS  while  an  eight  person 
crew  layout  might  be  needed  for  a  larger  UAS. 

Limiting  the  architecture  to  a  functional  level  enables  the  hardware  to  be 
customized  based  on  the  operating  environment  as  long  as  it  maintains  the  same 
functional  elements.  As  an  example,  a  mouse  is  a  2-D  input  device  that  can  be  used  well 
in  shore  based  GCS  applications  while  for  a  ship  or  airborne  control  station  it  might  not 
be  as  effective  since  it  can  move  with  the  motion  of  the  vehicle.  This  condition  may  lead 
to  the  use  of  a  trackball  instead.  The  functional  architecture  will  not  limit  this  type  of 
hardware  change. 

Since  the  equipment  may  be  mounted  in  different  operating  environments,  it  may 
become  necessary  to  use  hardware  that  is  more  robust  based  on  its  intended  operational 
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environment.  A  shipboard  GCS  might  need  humidity  and  salt  resistant  eomputer 
hardware  and  antennae,  while  a  land  based  GCS  would  have  less  stringent  environmental 
requirements.  This  arehiteeture  will  be  able  to  support  different  physieal  alloeations 
while  ensuring  a  functional  allocation  that  is  common.  Therefore,  the  system  will  be 
modular  and  scalable  per  Requirement  9  found  in  Table  8. 

2.  Enabling  Common  AVO  Training 

Through  the  requirements  analysis  and  the  list  of  requirements  in  Chapter  VI. B, 
the  need  for  common  AVO  training  was  found  to  have  a  derived  requirement  of  common 
AVO  HMI  for  control  of  the  air  vehicle.  This  common  HMI  also  needs  to  be  in  the  form 
of  a  directed  type  AVO  interface  vice  a  controlled  AVO  interface  as  discussed  in  Chapter 
VI.B. 


The  architecture  also  needs  to  separate  the  AVO  HMI  from  the  payload  HMI  to 
facilitate  easier  interface  changes  to  the  GCS.  This  will  allow  AVOs  to  use  an  interface 
without  interdependencies  on  the  payload  HMIs  that  can  vary  so  radically  between  air 
vehicle  types. 

Lastly,  from  the  requirement  in  Chapter  VI.B,  use  of  a  common  mission  planning 
tool  enables  all  AVOs  to  be  trained  on  the  use  of  a  single  common  interface  for  mission 
planning.  This  will  facilitate  even  greater  commonality  in  pilot  training. 

3.  Enabling  Interoperability 

In  addition  to  common  AVO  training,  the  research  revealed  other  requirements 
for  a  common  GCS  architecture.  An  important  requirement  is  for  a  level  of 
interoperability  between  the  GCS  and  different  types  of  UAS  air  vehicles.  This  was 
captured  in  the  Requirement  6  found  in  Table  8. 

To  help  with  interoperability.  Requirements  7  and  8  found  in  Table  8  show  that 
the  GCS  will  need  a  common  way  to  have  data  link  management.  This  will  facilitate  the 
use  of  common  forms  of  both  voice  and  data  formats  that  can  be  used  by  all  UASs  that 
work  with  the  common  GCS. 
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The  architecture  is  designed  to  have  separate  air  vehicle  control  to  translate 
internal  GCS  system  commands  into  a  standard  common  control  format  for  the  UAS  air 
vehicle.  This  will  enable  interoperability  while  allowing  the  GCS  to  maintain  different 
hardware  in  the  physical  architecture  and  allowing  the  architecture  to  remain  scalable. 

B.  ARCHITECTURAL  SYNTHESIS  FROM  AN  AIR  VEHICLE  CONTROL 

PERSPECTIVE 

The  initial  step  in  developing  the  architecture  was  to  develop  an  external  systems 
diagram  that  depicts  the  system,  external  systems,  and  context  [Buede,  2009]. 
Development  of  the  JUCCS  architecture  was  influenced  by  the  segregation  of  the  HMI  as 
a  separate  functional  area  as  first  seen  in  the  BAMS  architecture.  The  JUCCS  external 
systems  diagram  illustrates  the  UAS,  the  external  entities,  and  the  relationships  between 
the  UAS  and  the  entities  as  shown  in  Figure  27.  The  UAS,  shown  as  block  CO,  consists 
of  both  the  UAV  and  the  GCS. 

A  unique  approach  in  developing  the  external  diagram  was  the  inclusion  of  block 
Cl,  the  Area  of  Interest  (AOI),  Contact  of  Interest  (COI),  and  Target  of  Interest  (TOI). 
None  of  the  examined  UAS  architectures  had  included  these  elements  although  the 
elements  communicate  and  exchange  data  and  energy  with  the  UAS.  Another  unique 
approach  in  the  architecture  development  was  to  include  the  threat  information  in  block 
C6.  Threats  can  come  in  the  form  of  directed  energy,  cyber  attack  (non-kinetic  attacks) 
and  physical  attacks  (kinetic  attacks).  AOIs,  COIs,  TOIs  and  the  potential  threats  impact 
the  requirements  needed  for  the  survivability  and  operational  effectiveness  of  the  UAS. 
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Figure  27.  JUCCS  External  Systems  Block  Diagram 

JUCCS  external  systems  diagram  illustrating  the  UAS,  external  entities  and  relationships.  Unique 
characteristics  of  this  architecture  can  be  seen  with  the  inclusion  of  block  Cl  (AOI,  COI,  TOI)  and  block 

C6  (Threat). 


1.  UAS  Elements  and  Functions 

The  UAS  consists  of  two  major  elements,  the  GCS  and  the  UAV.  The  GCS  is  the 
ground  control  component  that  performs  all  the  functions  to  control  the  UAV  and 
interfaces  with  external  entities  to  ensure  the  mission  is  executed.  The  UAV  is  the 
mobile  air  element  of  the  UAS  that  utilizes  onboard  payloads  (sensors,  weapons,  etc.)  and 
communications  to  execute  the  mission. 

The  GCS  interactively  communicates  externally  with  the  UAV,  various  command 
elements,  air  traffic  control  elements,  and  the  customers.  The  GCS  interacts  and  receives 
data  and  energy  from  the  environment  in  the  form  of  weather  and  Electromagnetic 
Environmental  Effects  (E3).  The  GCS  may  also  receive  energy  or  data  from  various 
threats. 


The  GCS  controls  piloting,  navigation,  and  payload  (sensor,  weapon,  etc.) 
functions  of  the  UAV.  The  GCS  operator  directs  the  takeoff,  navigation,  flight  path,  and 
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landing  of  the  UAV.  The  GCS  eontrols  the  sensor  payload  of  the  UAV  that  ineludes 
sensor  status,  video  and  data  eontrol,  and  eontrol  of  the  physieal  operation  of  the  sensors. 
The  sensor  payload  can  include  EO/IR,  radar,  SIGINT,  as  well  as  other  sensor  payloads. 
The  GCS  controls  the  payload  functions  of  weapon  payloads  of  the  air  vehicle  including: 
status,  selection,  programming,  data  and  video,  and  control. 

The  UAV  provides  mobile  capabilities  to  execute  the  mission.  The  UAV 
provides  the  following  functions:  1)  Communications  to  the  GCS  which  include  platform 
status,  position,  and  control  feedback.  2)  Weapons  and  sensor  status  and  control 
feedback  to  the  GCS.  Sensor  data  can  include  sensor  status,  video,  and  data  such  as 
EO/IR,  radar,  and  SIGINT.  Sensor  control  includes  feedback  from  the  sensors  located  on 
the  UAV.  Weapon  data  includes  weapon  type,  status,  video,  and  data  from  the  weapon 
on  or  launched  from  the  air  vehicle.  3)  UAV  to  customer  communications  including  all 
sensor  status,  data,  control,  and  feedback.  4)  UAV  to  Air  Traffic  Control  (ATC) 
communications  where  ATC  information  includes  Identification  Eriend  or  Eoe  (lEE) 
interrogator  and  transponder  information  and  sense-and-avoid  information  such  as  the 
Traffic  Collision  Avoidance  System  (TCAS).  5)  UAV  to  threat  sensing  including 
constantly  scanning  for  E3,  cyber,  and  weapons  threats.  6)  UAV  to  AOI,  COI,  and  TOI 
sensing  that  includes  energy  that  is  sent  from  or  received  by  the  UAV  sensors. 

2.  External  Entities  and  Functions 

External  entities  include  command  elements,  AOIs,  COIs,  TOIs,  air  traffic, 
customers,  environment,  and  threats.  A  summary  of  the  context  and  relationships  with 
the  UAS  are  described  in  the  following  paragraphs. 

Command  elements  provide  tasking  and  management  of  the  UAS  such  as  mission 
and  reporting  requirements.  The  command  element  includes  strategic,  tactical,  and 
coalition  command  and  control  elements.  Tasking  includes  communication  regarding 
mission  planning  and  execution.  UAS  status  is  the  current  operational  status  of  the  GCS 
and  the  UAV,  which  could  include  health  and  position  data.  Weapons  authorization 
includes  authorization  for  weapons  release  and  weapon  information  that  includes  type. 
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status,  data,  and  video.  Sensor  data  ineludes  sensor  status,  video,  and  data  that  eould 
include  EO/IR,  radar,  and  SIGINT. 

The  areas  and  items  deemed  important  to  the  UAS  mission  include  AOIs,  COIs, 
and  TOIs.  The  AOIs  include  all  large  and  small  ground  and  ocean  area  surveillance. 
COIs  include  all  specific  surveillance  items  of  interest:  personnel,  vehicles,  weapon 
systems,  aircraft,  boats,  ships,  buildings,  and  facilities.  TOIs  include  adversary 
personnel,  vehicles,  weapon  systems,  aircraft,  boats,  ships,  buildings,  and  facilities. 
Energy  transmitted  to  or  from  the  UAV  is  any  electromagnetic  energy:  RE,  EO/IR, 
emitted  or  reflected  by  the  UAV  or  AOI,  COI,  TOI  and  is  detectable  by  the  UAV  sensor 
suite.  An  example  of  an  energy  flow  is  RE  energy  in  the  form  of  a  radar  pulse  that  is 
emitted  by  the  UAV  and  reflected  from  a  TOI  back  to  the  UAV  radar  sensor.  Data  is 
transmitted  to  or  received  from  a  COI.  An  example  of  data  to  and  from  a  COI  would  be 
Blue  Eorce  Tracker  data  that  indicates  the  status  and  position  of  friendly  forces. 

Air  traffic  includes  all  civilian  and  military  air  traffic  and  air  traffic  control 
elements  within  communications  range  of  the  air  vehicle  [NASA,  2010].  ATC 
information  includes  Air  Traffic  Management  (ATM)  and  air  traffic  data.  ATM  includes 
all  voice  and  data  that  affects  the  flight  path  and  safety  of  the  UAV.  ATM  elements 
include:  1)  lEE  interrogator  and  transponder  information  and  sense  and  avoid 
information  such  as  TCAS.  2)  External  entities,  such  as  a  local  airport  air  traffic  control 
elements  that  direct  the  UAV  flight  path,  altitude,  and  heading  and  provide  current  flight 
safety  data  such  as  weather,  air  traffic,  radio  frequencies,  and  routing  information.  The 
air  traffic  data  includes  voice  and  data  air  traffic  command  and  control  information  to  and 
from  the  UAS  ground  station.  The  air  traffic  data  could  include  Elight  Service  Station 
(ESS)  information  such  as  ATC  clearances,  and  recordings  for  Notices  to  Airmen 
(NOTAMs).  The  ESS  broadcasts  aviation  weather  and  National  Airspace  System  (NAS) 
information.  The  station  receives  and  processes  VER  and  lER  flight  plans,  and  monitors 
navigation  aids.  In  addition,  at  selected  locations,  an  ESS  provides  an  En  Route  Elight 
Advisory  Service  (Elight  Watch),  gathers  weather  data,  and  issues  airport  advisories.  The 
ESS  also  advises  U.S.  Customs  and  Immigration  of  trans-border  flights  [NASA,  2010]. 
The  customer  element  can  include  strategic,  tactical,  and  coalition  elements.  Customer  to 
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UAV  communication  includes:  1)  Sensor  status,  video,  and  data  that  eould  inelude 
EO/IR,  radar,  and  SIGINT.  2)  Sensor  eontrol  ineludes  sensor  eontrol  information  and 
feedbaek  from  the  sensors  loeated  on  the  UAV.  3)  Weapons  data  ineludes  weapon  type, 
status,  video,  and  data  from  the  weapon  on  or  launched  from  the  air  vehiele.  4)  Weapon 
authority  is  the  weapon  control  including  launch,  feedback,  and  programming  of  the 
weapon.  Customer  to  GCS  eommunications  includes  the  following  data  elements:  1) 
Tasking  is  eommunieation  regarding  mission  planning  and  execution.  2)  Sensor  data  is 
sensor  status,  video,  and  data  that  eould  inelude  EO/IR,  radar,  and  SIGINT.  3)  Weapon 
eontrol  ineludes  launeh,  feedbaek,  and  programming  of  the  weapon. 

The  external  environmental  effeets  inelude  both  weather  and  E3.  Weather  affeets 
operation  of  both  the  GCS  and  UAV.  Weather  ean  affeet  the  physieal  operation  of  the 
UAS  in  temperature,  rain,  snow,  sleet,  sand,  dust,  wind,  etc.  Operation  ean  mean  the 
ability  to  operate  the  equipment  in  all  weather  eonditions,  to  inelude  communications  and 
sensing.  E3  affeets  both  the  GCS  and  UAV  from  electromagnetie  effects  including  those 
emanating  from:  oommunieations,  jammers,  radars,  ete.  E3  ean  also  include  large  scale 
eleetromagnetie  pulses  from  nuelear  detonation  as  well  as  lightning. 

The  threat  element  ean  inelude  all  manner  of  threats  that  affeet  both  the  GCS  and 
the  UAV.  Threats  inelude:  E3  threats  from  jammers  and  spoofers,  eyber  threats  that 
include  illegal  haeking  of  networks  or  information  either  through  the  air  or  by  tapping 
into  land  lines,  kinetie  weapons  that  include  everything  from  small  arms  to  missiles,  and 
non-kinetie  Chemieal,  Biologieal,  and  Radiologieal  (CBR)  threats  to  the  GCS. 

C.  CREATING  THE  JUCCS  FUNCTIONAL  ARCHITECTURE  WITH 

BLOCK  DIAGRAMS 

The  funetional  arehiteeture  was  ereated  from  the  external  systems  diagram  by 
developing  funetions  from  the  relationships  between  the  GCS,  UAV,  and  the  external 
entities.  Relevant  examples  were  utilized  from  existing  programs  and  system  engineering 
guidanee  ineluding:  The  Engineering  Design  of  Systems  [Buede,  2009],  Systems 
Engineering  and  Analysis  [Blanchard  &  Eabrycky,  2006],  DoD  Architecture  Eramework 
[Dam,  2006],  BAMS  Architecture,  and  notes  from  various  NFS  classes  and  professors. 
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The  main  functions  were  developed  using  the  GCS  system  requirements  in 
Chapter  VLB  and  the  external  context  diagram.  The  first  step  was  to  decompose  the 
UAS  block  of  the  external  systems  diagram  into  GCS  and  air  vehicle  functions  as  shown 
in  Figure  28.  The  decomposition  of  the  UAS  system  functions  follow  by  decomposing 
the  GCS  and  air  vehicle  functions  linked  to  the  data  from  the  external  entities  in  the 
external  context  diagram. 


Weather 

E3 

Data  Transfer 
(from  Customer) 

Threat  Attack 
(Kinetic,  Non- 
Kinetic) 


Data  from  COI 

Energy  from 
AOI-COI-TOI 


Figure  28.  JUCCS  UAS  Block  Diagram 

JUCCS  UAS  functional  block  diagram  showing  external  entities,  GCS  and  Air  Vehicle  Functions,  and  the 

data  elements  between  them. 


1 .  Top  Level  Hierarchy  of  JUCCS  Architecture 

The  top  level  hierarchal  JUCCS  systems  diagram  was  developed  from  the 
external  systems  diagram  and  the  context  of  the  external  elements  as  shown  in  Figure  29. 
The  UAS  was  first  decomposed  into  two  functions  relating  to  the  GCS  and  the  air 
vehicle.  The  functions  of  the  air  vehicle  are  not  included  at  this  time  as  the  concentration 
is  on  the  control  of  the  air  vehicle  from  the  GCS.  The  GCS  was  further  decomposed  into 
eight  sub-functions:  Provide  Human  Interface,  Plan  Mission,  Manage  Mission, 
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Command  and  Control  Air  Vehicle,  Control  Payload,  Process  Payload  Data,  Manage 
Communications  and  Disseminate  Data,  and  Perform  External  Communications.  Further 
decomposition  will  take  place  on  only  three  of  the  GCS  sub-functions:  Provide  Human 
Interface,  Manage  Mission,  and  Command  and  Control  Air  Vehicle.  This  is  due  to  the 
project  focus  on  common  training  by  having  a  common  HMI  for  air  vehicle  control. 
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A1.2 

At  .3 

A1.4 

Provide  Human 
Interface 

Plan  Mission 

Manage  Mission 

Command  and 
Control  Air  Vehicle 

A1.5 

A1.6 

A1.7 

A1.8 

Control  Payload 

Process  Payload 
Data 

Manage  Comms  & 
Disseminate  Data 

Perform  External 
Comms 

Figure  29.  JUCCS  Architecture  Top  Level  Hierarchy 

JUCCS  Architecture  highlighting  the  emphasis  on  the  GCS  functions,  including  the  Provide  Human 
Interface,  Manage  Mission  and  Command  and  Control  Air  Vehicle  functional  elements.  Blocks  shown  in 

blue  are  further  decomposed  in  the  architecture. 


2.  A1  Block  Diagram:  Perform  GCS  Functions 

The  A1  diagram  is  the  main  functional  component  for  a  common  GCS.  There  are 
external  entities  that  feed  data  to  the  GCS  including  the  air  vehicle  which  is  internal  to 
the  system,  and  various  external  entities.  The  main  functional  architecture  of  the  GCS  is 
made  up  of  eight  functions.  These  functions  can  be  seen  in  the  following  list  and  in 
Figure  30. 
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•  A  1.1  Provide  Human  Interface 

•  A  1.2  Plan  Mission 

•  A  1.3  Manage  Mission 

•  A1.4  Command  and  Control  Air  Vehicle 

•  A  1.5  Control  Payload 

•  A1.6  Process  Payload  Data 

•  A  1.7  Manage  Comms  and  Disseminate  Data 

•  A  1.8  Perform  External  Comms 
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Figure  30.  JUCCS  Perform  GCS  Functions  Block  Diagram 

This  diagram  shows  the  eight  functions  that  comprise  the  Perform  GCS  functions  and  their  associated  data 
flows.  Blocks  shown  in  blue  are  further  decomposed  in  the  architecture. 

Al.l  Provide  Human  Interface  is  the  function  that  provides  all  the  interaction 
between  the  system  and  the  human  operators.  All  of  the  system  human  interfaces  from 
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system  output  to  the  operator  (visual,  aural,  or  taetile)  and  inputs  to  the  system  through 
input  deviees  (mouse,  keyboard,  joystiek,  ete)  are  funetionally  modeled  here.  This  is  the 
funetion  that  interaets  with  the  rest  of  the  system  through  the  funetions  A1 .2,  A1.3,  A1.6, 
and  A1.7. 

A1.2  Plan  Mission  is  the  mission  planning  funetion.  One  of  the  derived 
requirements  for  eornmon  training  is  that  a  eornmon  mission  planning  system  be  used  and 
mandated  through  a  common  GCS.  This  function  is  separate  and  its  own  functional 
module  to  ensure  that  a  new  mission  planning  system  can  be  changed  in  the  architecture. 

A1.3  Manage  Mission  is  the  function  that  is  the  central  point  of  the  system 
operations.  It  takes  in  the  information  from  the  air  vehicle  including  aircraft  telemetry, 
AV  system  status,  payload  status,  payload  data,  mission  plan  information,  and  then  uses 
those  to  interpret  the  operator  input  from  Ai.i  Provide  Human  Interface.  A1.2  is  where 
the  system  keeps  track  of  the  air  vehicle,  where  it  is,  what  it  is  doing,  and  allows  the 
operator  commands  to  occur. 

A1.4  Command  and  Control  Air  Vehicle  provides  the  translator  function  taking 
internal  system  commands  and  converting  them  to  a  standard  interoperable  language  that 
all  UAVs  can  understand.  This  will  address  the  requirement  for  interoperable  AV 
control.  This  function  is  also  modular  and  separate  from  the  payload  control  to  ensure 
that  either  function  can  be  changed  in  the  physical  architecture  without  having 
interactions  change  with  the  other  to  meet  the  requirement  of  separating  the  AV  control 
and  the  payload  control. 

A1.5  Control  Payload  is  the  function  that  allows  control  of  the  payloads.  These 
payloads  can  be  sensors,  weapons,  or  other  devices.  The  need  here  is  to  separate  the 
payload  control  from  the  AV  control  as  payloads  can  vary  widely  from  air  vehicle  type  to 
type.  This  function  translates  the  specific  system  commands  to  the  payload  commands 
necessary  for  that  type  of  payload.  This  allows  specific  changes  in  this  functional 
module  to  be  more  readily  changed  when  payloads  are  changed. 
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A1.6  Process  Payload  Data  allows  for  the  raw  payload  data  from  different 
payloads  to  be  manipulated  by  the  operator.  The  raw  data  is  input  to  the  funetion  and  the 
operator  ean  ehange  the  metadata,  format,  or  fuse  with  other  information.  An  example  of 
this  eould  be  taking  a  Synthetie  Aperture  Radar  (SAR)  image  and  marking  targets  of 
interest  or  assoeiating  eleetro-optieal  imagery  with  geographie  loeations. 

A1.7  Manage  Comms  and  Disseminate  Data  is  a  funetion  that  eontrols  what  data 
leaves  the  GCS.  It  directly  handles  information  internal  to  the  system  (between  the  GCS 
and  the  AV)  and  governs  the  format  and  data  type.  For  communications  external  to  the 
system,  the  recipient  and  data  is  sent  to  A1.8  Perform  External  Comms. 

A1.8  Perform  External  Comms  takes  data  from  the  AL7 Manage  Comms  and  will 
format  and  send  to  the  directed  external  entity.  This  function  allows  the  separation  of 
communication  functionality  between  those  that  are  internal  to  the  system  (between  GCS 
and  the  AV)  and  those  that  are  between  the  GCS  and  other  entities  external  to  the  GCS. 
It  needs  to  be  noted  that  some  communications  from  the  air  vehicle  to  other  external 
entities  are  still  handled  in  the  GCS  by  AL7  Manage  Comms  because  some 
communications  data  can  be  ported  to  the  air  vehicle  and  then  transmitted  from  the  air 
vehicle  to  entities  external  to  the  system. 

D.  DOCUMENTING  AND  LINKING  THE  ARCHITECTURE  WITH  CORE® 

The  JUCCS  architectural  team  realized  that  a  Model  Based  Systems  Engineering 
(MBSE)  tool  would  be  beneficial  due  to  the  complexity  of  the  proposed  functional 
architecture.  There  are  several  MBSE  tools  available  for  systems  engineering  design  and 
two  common  choices  are  Vitech  Corporation’s  CORE®  and  IBM’s  Rational  System 
Architect.  The  JUCCS  architectural  team  chose  CORE®  since  a  student  license  was 
already  established  from  earlier  NFS  classes  and  the  JUCCS  architecture  team  was 
familiar  with  the  basic  operation  of  the  CORE®  software.  CORE®  Enterprise  version 
5.1.5  was  used  to  document  the  JUCCS  functional  architecture.  The  JUCCS  architectural 
team  used  the  formerly  described  architectural  synthesis  to  identify  the  boundaries 
between  the  UAS  and  the  external  environment. 
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The  CORE®  software  allows  the  use  of  either  Enhaneed  Funetional  Flow  Block 
Diagrams  (EFFBD)  or  the  Integration  Definition  for  Functional  Modeling  (IDEFO)  as  an 
architectural  format.  The  EFFBD  is  used  “for  capturing  dynamic  behavior  in  a 
representation  that  can  be  simulated”  [Buede,  2009].  IDEFO  is  a  process  model  which 
addresses  “how  outputs  are  transformed  from  inputs  via  some  function,  activity,  or  task” 
[Buede,  2009].  The  complex  interaction  between  multiple  functions  within  the  UAS  is 
more  suited  to  the  functional  and  non-linear  IDEFO  format,  so  this  is  the  format  that  was 
chosen  by  the  JUCCS  architectural  team. 

The  IDEFO  format  consists  of  several  functional  blocks  per  diagram,  and  each 
block  can  consist  of  four  activities.  These  activities  consist  of  the  Inputs,  Controls, 
Outputs,  and  Mechanisms  (ICOM).  The  input  is  an  activity  flow  that  enters  the 
functional  block  from  the  left.  The  control  has  an  effect  on  the  function  and  enters  the 
block  from  the  top.  The  output  captures  what  the  function  has  done  and  exits  the  block 
from  the  right.  Finally  the  mechanism,  although  not  used  in  the  JUCCS  functional 
architecture,  is  an  external  entity  that  can  affect  the  function.  It  is  recommended  that 
each  functional  level  contain  three  to  six  functional  blocks.  Some  of  the  JUCCS  IDEFO 
diagrams  consist  of  as  many  as  eight  functional  blocks  and  as  few  as  two.  The  JUCCS 
architectural  team  determined  these  variations  from  the  IDEFO  recommendations  were 
warranted  in  order  to  properly  describe  the  corresponding  functions  [Knowledge  Based 
Systems,  Inc.,  2010]. 

During  the  initial  design,  each  of  the  major  functions  within  the  UAS  system  was 
defined  based  on  the  functional  requirements  detailed  in  Chapter  VI. B.  These  major 
functions  provided  the  backbone  for  the  JUCCS  functional  architecture  and  it  was  during 
this  initial  design  that  the  CORE®  software  proved  useful.  When  data  flow  linkages 
between  functions  at  different  levels  were  not  consistent  the  CORE®  software  provided 
indications  of  the  inconsistencies.  The  inconsistencies  could  then  be  adjudicated  and 
corrected  to  allow  consistent  functional  flow. 

Additionally,  further  usefulness  of  the  CORE®  software  was  realized  when 
editing  and  making  changes  to  the  functional  architecture.  An  artifact  of  using  the 
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CORE®  MBSE  tool  is  that  changes  made  at  one  level  were  properly  refleeted  at  lower 
levels  or  an  indicator  identifled  an  inconsistency.  Since  the  JUCCS  functional 
architecture  went  through  seven  major  revisions,  the  tool  enabled  the  JUCCS 
architectural  team  to  quickly  and  accurately  make  ehanges  that  would  have  been  difficult 
to  track  if  an  MBSE  tool  was  not  used. 

E.  JUCCS  PROPOSED  COMMON  GCS  ARCHITECTURE 

As  diseussed,  the  architectural  views  were  developed  using  an  IDEFO  approaeh. 
The  IDEEO  funetions  were  decomposed  only  to  the  level  needed  to  show  the  air  vehiele 
control  functions  and  to  those  levels  necessary  to  show  that  the  requirements  in  Chapter 
VLB  for  eornmon  training  are  demonstrated  by  the  arehitecture.  Eaeh  sub-funetion  was 
then  modeled  in  IDEFO  to  ensure  consistent  data  flow  between  levels. 

1.  A-1:  External  Systems  Diagrams 

The  initial  context  diagram,  shown  in  Figure  27,  was  modeled  in  IDEFO.  This 
was  aceomplished  by  creating  an  external  system  diagram,  shown  in  Figure  31,  and 
defining  the  different  data  flows  between  the  elements.  The  IDEFO  version  of  the 
original  diagram  results  in  a  greater  resolution  of  what  data  flows  between  elements  and 
in  what  direetion  that  data  flows. 
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Figure  31.  JUCCS  IDEFO  A-1  External  Systems  Diagram 

The  external  context  diagram  in  IDEFO  format  shows  the  external  entities  that  are  outside  the  system  (CO)  and  how  they  interact  with  the  system.  The 

block  shown  in  green  (UAS)  has  been  further  decomposed  in  the  architecture. 
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As  discussed,  the  A-1  external  diagram  here  is  the  IDEFO  version  of  Figure  27. 
The  descriptions  of  each  of  the  external  entities  and  how  they  interact  with  diagram  have 
already  been  discussed  and  ean  be  found  in  Chapter  VII. C. 

2,  AO:  UAS  Node  Diagram 

The  AO  JUCCS  UAS  node  diagram  was  modeled  in  IDFFO  as  shown  in  Figure 
32.  This  was  aeeomplished  by  taking  the  JUCCS  UAS  block  diagram  shown  in  Figure 
28  and  defining  the  different  data  flows  between  the  elements.  The  IDFFO  version  of  the 
diagram  results  in  a  greater  resolution  of  what  data  flows  between  elements  and  in  what 
direction  that  data  flows. 


Figure  32.  JUCCS  IDEFO  AO  UAS  Node 


This  diagram  shows  the  two  internal  nodes  of  the  AO  system  diagram.  They  include  the  Air  Vehicle  and  the 
Ground  Control  Station  functions.  Only  the  Ground  Control  Station  functions  shown  in  the  green  block  will 

be  decomposed  in  this  architecture. 
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The  IDEFO  AO  diagram  shows  the  two  funetions  of  the  UAS  as  a  whole  system. 
They  are  the  Perform  Ground  Control  Station  Functions  and  the  Perform  Air  Vehicle 
Functions.  The  deseriptions  for  these  funetions  are  located  in  Chapter  VII.C.l.  The 
information  flows  from  the  A-1  external  nodes  are  shown  in  the  diagram.  They  represent 
the  interactions  of  the  external  entities  with  both  functions  of  the  UAS,  as  well  as  how  the 
two  functions  of  the  UAS  pass  data  between  the  Perform  GCS  Function  and  the  Perform 
Air  Vehicle  Function. 

3.  Al:  Perform  GCS  Functions 

Perform  GCS  Functions  details  the  overall  system  functions  for  the  GCS.  The 
IDEFO  diagram  of  Al  Perform  GCS  Functions  can  be  seen  in  Figure  33.  This  IDEFO 
depiction  shows  all  of  the  data  flows  between  the  GCS  functions.  It  is  important  to  see 
that  all  communication  from  the  air  vehicle  comes  through  A1.7  Manage  Comms.  This 
includes  things  that  are  transmitted  to  the  air  vehicle  from  sources  external  to  the  system 
and  then  sent  from  the  air  vehicle  to  the  GCS.  All  communication  that  arrives  at  the  GCS 
from  sources  external  to  the  system  arrives  through  Ai. 5  Perform  External  Comms. 
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Figure  33.  JUCCS  IDEFO  A1  Perform  GCS  Functions 

This  IDEFO  diagram  shows  the  eight  functions  that  comprise  the  Perform  GCS  functions  and  their  associated  dataflows.  The  blocks  shown  in  green 

have  been  further  decomposed  in  the  architecture. 
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The  IDEFO  A1  diagram  shows  the  eight  functions  of  the  GCS  as  a  system.  The 
descriptions  for  these  functions  are  located  in  Chapter  VII. C. 2.  The  information  flows 
from  the  AO  external  nodes  and  from  the  Perform  Air  Vehicle  Functions  node  are  shown 
in  the  diagram.  They  represent  the  interactions  of  the  external  entities  with  the  GCS 
functions  as  well  as  how  the  two  functions  of  the  UAS  pass  data  between  them. 

4.  Al.l:  Provide  Human  Interface 

The  Al.l  Provide  Human  Interface  function  is  a  top  level  GCS  function.  It 
breaks  out  the  human  machine  interface  for  all  operator  actions  into  a  separate  function. 
The  functional  architecture  of  the  Provide  Human  Interface  is  made  up  of  six  functions: 

•  A  1.1.1  Perform  Security  and  Role  Based  Access 

•  A  1.1.2  Provide  HMl  Setup  Management 

•  Al.l. 3  Provide  Mission  Planning  Interface 

•  Al.l. 4  Interface  with  Mission  Management  Control 

•  Al.l. 5  Provide  Payload  Data  Processing  Interface 

•  Al.l. 6  Provide  Communication  and  Data  Dissemination  Interface 

Of  these  functions,  Al.l. 4  Interface  with  Mission  Management  Control  will  be 
decomposed  further  to  show  the  AVO  human- machine  interface.  These  six  functions 
can  be  seen  in  context  in  Figure  34. 
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Figure  34.  JUCCS  IDEFO  All  Provide  Human  Interface 

The  Provide  Human  Interface  function  allows  all  the  operator  interfaces  to  be  grouped  together  in  one  functional  group.  1.1.4  Interface  with  Mission 

Management  Control  will  be  further  decomposed  to  show  the  AVO  Human-Machine  Interface. 
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Al.1.1  Perform  Security  and  Role  Based  Access  is  the  function  that  provides  the 
interface  to  log  into  the  system.  The  function  will  then  ensure  that  the  person  has  the 
security  clearance  to  use  the  system.  It  will  then  find  the  role  that  allows  that  operator  to 
access  certain  functions  and  therefore  certain  HMI  functions  and  not  others  depending  on 
the  role  that  has  been  set  up  for  that  person.  It  will  provide  the  user  access  to  the  other 
functions  in  Al.l  to  allow  for  their  use  through  the  validated  user  access  data.  The 
function  will  allow  the  pass  through  of  mission  data  through  the  Al.1.1  to  the  other 
functions. 

Al.l. 2  Provide  HMI  Setup  Management  is  the  function  that  allows  a  validated 
user  to  change  the  way  information  is  presented  to  them.  It  can  allow  for  setting  of 
parameters  such  as  the  volume  or  tone  of  aural  information.  It  can  allow  the  setting  of 
parameters  such  as  the  colors  or  size  of  visual  information.  It  can  also  allow  the  setup  of 
parameters  for  tactile  information  such  as  vibration  Ifequency  or  amplitude  of  a  controller 
or  chair.  It  could  also  allow  setup  of  the  input  devices  such  as  cursor  scroll  rate,  etc. 

Al.l. 3  Provide  Mission  Planning  Interface  is  the  function  that  provides  the 
interface  for  the  mission  planning  function  of  the  GCS.  It  will  allow  the  HMI  to  the 
authorized  operator  to  plan  the  UAS  AV  mission  plan  and  transfer  the  data  to  the 
function  A i. 2  Plan  Mission. 

Al.l. 4  Interface  with  Mission  Management  Control  is  the  function  that  provides 
the  interface  for  A  1.4  Manage  Mission.  Inside  of  this  functional  area  the  HMI  for  the 
AVO  interface  necessary  to  meet  the  JUCCS  requirement  I,  2,  3,  and  4  are  located.  This 
function  will  be  further  decomposed  as  shown  in  Figure  35. 

Al.l. 5  Provide  Payload  Data  Processing  Interface  is  the  function  that  provides 
the  HMI  for  the  A1.6  Process  Payload  Data.  This  interface  will  control  how  the  raw 
payload  data  is  manipulated,  annotated,  and  fused  by  the  operators. 

Al.l. 6  Provide  Communication  and  Data  Dissemination  is  the  function  that 
provides  the  HMI  for  the  A1.7  Manage  Comms  and  Disseminate  Data.  This  function 
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allows  for  the  selection  of  data  transmission  paths,  carrier  frequencies,  etc.  to  flow  to  the 
UAS  AV  and  to  sources  external  to  the  GCS. 


The  decomposition  of  Al.  1.4  Interface  with  Mission  Management  Control  can  be 
seen  in  Figure  35. 
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Figure  35.  JUCCS  IDEFO  A114  Interface  with  Mission  Management  Control 


The  Interface  with  Mission  Management  Control  IDEFO  diagram  shows  the  operator  interface  for  mission, 
air  vehicle  and  payload  control.  The  block  shown  in  green  is  further  decomposed  in  the  architecture. 


The  Al.1.4  Interface  with  Mission  Management  Control  IDEFO  diagram  shows 
the  interaction  between  the  JUCCS  common  HMI  and  the  mission  management 
functions.  Mission  management  functions  consist  of  the  operator  interface  for  mission, 
air  vehicle  and  payload  control.  The  user  setup  preferences  control  input  consists  of  that 
specific  operator’s  stored  preferences.  The  specific  operator  is  authenticated  using  the 
validated  user  access  control  to  ensure  air  vehicle  commands  only  come  from  authorized 
operators.  The  Al.  1.4.1  Interface  with  Mission  Control  functional  block  provides  the 
main  input  linkage  and  parses  out  the  air  vehicle  or  payload  control  as  required.  The 
center  function,  Al.  1.4.2  Interface  with  Air  Vehicle  Control  functional  block,  is  shown  in 
green  and  is  further  decomposed  to  show  how  common  air  vehicle  training  benefits  can 
be  realized  by  this  function.  The  Al.1.4. 3  Interface  with  Payload  Control  functional 
block  provides  the  operator  interface  for  controlling  the  specific  payload.  Due  to  the 
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multiple  different  types  of  payloads  which  consist  of  weapons  and  sensors  and  their 
proprietary  nature,  this  was  not  a  function  where  the  JUCCS  architectural  team  focused 
their  attention  in  order  to  realize  commonality. 
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Figure  36.  JUCCS  IDEFO  A1142  Interface  with  Air  Vehicle  Control 

The  Interface  with  Air  Vehicle  Control  IDEFO  diagram  is  the  lowest  decomposition  of  the  operator 
interface  with  the  air  vehicle.  The  actual  human  operator  resides  within  the  Interact  with  Human  Operator 

functional  block  shown  in  the  center  as  1.1. 4.2.2. 


The  Al.  1.4.2  Interface  with  Air  Vehicle  Control  IDEFO  diagram  consists  of  the 
functions  that  deal  with  how  the  current  air  vehicle  mission  information  is  presented  to 
the  operator.  The  user  setup  preferences  control  input  consists  of  that  specific  operator’s 
stored  preferences.  The  specific  operator  is  authenticated  using  the  validated  user  access 
control  to  ensure  air  vehicle  commands  only  come  from  authorized  operators.  The 
Al. 1.4.2. 1  Convert  Data  to  Desired  Format  functional  block  translates  the  air  vehicle 
information  to  audio,  visual  or  tactile  information,  or  any  combination  of  the  three, 
depending  on  what  is  appropriate  for  that  particular  data  and  the  operator’s  preferences. 
This  translated  air  vehicle  information  is  provided  to  the  Al.  1. 4.2.2  Interact  with  Human 
Operator  functional  block  which  is  where  the  human  operator  resides.  The  human 
operator  then  makes  decisions  and  provides  unformatted  inputs,  through  system  input 
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devices  such  as  a  keyboard,  mouse,  joystick,  touch-screen,  etc.  This  unformatted  data  is 
sent  to  the  Al.  1.4.2. 3  Format  and  Disseminate  Inputs  and  System  Status  functional  block 
which  translated  the  unformatted  input  into  an  air  vehicle  or  mission  management 
command.  An  example  of  this  translation  would  be  the  raw  keyboard  data  being 
translated  from  the  American  Standard  Code  for  Information  Interchange  (ASCII)  to  the 
specific  command,  in  its  native  format,  going  to  the  air  vehicle,  based  on  the  operator’s 
keystrokes.  An  additional  output  from  the  Al.  1.4.2. 3  functional  block  is  the  detection  of 
the  operator’s  current  mission  setup  features  which  are  fed  back  up  into  the  Al.1.2 
Provide  FIMI  Setup  Management  functional  block  where  the  settings  are  stored  for  this 
operator’s  future  use. 

5.  A1.3:  Manage  Mission 

The  A1.3  Manage  Mission  function  is  a  top  level  GCS  function.  It  is  the  central 
function  that  the  GCS  system  works  through.  The  function  takes  current  information 
from  the  UAS  AV  status,  payload  information,  mission  plan,  and  uses  inputs  from  the 
operator  to  send  commands  out  to  the  system.  The  functional  architecture  of  Manage 
Mission  is  made  up  of  four  functions: 

•  A  1.3.1  Monitor  Mission 

•  Al. 3. 2  Assess  Mission 

•  Al.3.3  Update  Mission 

•  A  1.3. 4  Direct  System 

Of  these  functions,  the  Al.3.4  Direct  System  interface  with  A1.4  Command  and 
Control  Air  Vehicle  is  necessary  to  send  commands  to  the  UAS  AV  to  meet  JUCCS 
Requirement  6  and  7.  These  four  functions  can  be  seen  in  context  in  Figure  37. 
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Figure  37.  JUCCS  IDEFO  A13  Manage  Mission 

The  Manage  Mission  IDEFO  functional  diagram  provides  the  Monitor  Mission  and  Assess  Mission  functions.  Based  on  the  payload  or  air  vehicle 
operator  updated  commands,  the  payload  or  air  vehicle  is  provided  with  updated  commands  if  required. 
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The  A1.3  Manage  Mission  IDEFO  functional  diagram  shows  the  JUCCS 
architecture’s  four  major  mission  functions.  The  Al.3.1  Monitor  Mission  functional 
block  accepts  air  vehicle  information,  raw  payload  information  from  the  weapon  or 
sensor,  and  data  for  mission  planning  and  management  as  input  from  the  A1.2  Plan 
Mission  function.  This  information  is  translated  and  allows  the  operator  to  assess  the 
mission  at  the  Al.3.2  Assess  Mission  functional  block.  The  Assess  Mission  function  also 
allows  for  input  of  the  mission  plan  and  outputs  the  current  mission  parameters  and  the 
mission  management  data  for  human  use  which  feeds  back  into  the  HMI.  The  output 
from  Al.3.2  is  the  current  assessed  mission  data  from  the  operator  which  is  input  into  the 
Al.3.3  Update  Mission  functional  block  where  the  operator  makes  mission  changes  based 
on  the  current  data.  The  output  from  Al.3.3  is  the  raw  payload  data,  which  is  sent  to  the 
A1.6  Process  Payload  Data  functional  block,  and  the  mission  data,  which  is  sent  to  the 
A1.7  Manage  Comms  &  Disseminate  Data  functional  block.  The  final  output  from 
Al.3.3  is  the  system  direction  command  which  is  the  input  to  the  Al.3.4  Direct  System 
functional  block.  The  Direct  System  functional  block  then  formats  the  appropriate 
commands  for  the  air  vehicle  (which  is  an  input  to  A1.4  Command  and  Control  Air 
Vehicle)  and  the  payload  (which  is  an  input  to  Ai.5  Control  Payload). 

6.  A1.4:  Command  and  Control  Air  Vehicle 

The  A1.4  Command  and  Control  Air  Vehicle  function  is  shown  in  Figure  38.  It  is 
important  to  see  that  the  two  sub-functions  here  are  both  transfer  functions  that  translate 
system  specific  commands  into  a  standard  set  of  command  controls  to  facilitate  JUCCS 
Requirements  6  and  7  found  in  Table  8. 
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Figure  38.  JUCCS  IDEFO  A14  Command  and  Control  Air  Vehicle 

The  JUCCS  IDEFO  Command  and  Control  Air  Vehicle  is  where  the  proprietary  command  enters  the 
Control  Air  Vehicle  functional  block  and  is  translated  into  a  standard  command  output  (an  example  of 
which  would  be  the  STAN  AG  4586  interoperable  formatted  commands)  on  the  output.  Similarly  the 
formatted  air  vehicle  status  data  enters  the  Monitor  Air  Vehicle  functional  block  and  is  translated  to  its 
proprietary  air  vehicle  information  for  use  in  the  GCS.  Both  of  these  blocks  are  decomposed  further. 


The  A1.4  Command  and  Control  Air  Vehicle  IDEFO  diagram  consists  of  the 
Al.4.1  Control  Air  Vehicle  and  Al.4.2  Monitor  Air  Vehicle  functional  blocks.  While  the 
main  purpose  of  these  functional  blocks  is  to  control  and  monitor  the  air  vehicle,  here  is 
where  the  main  tenets  of  STANAG  4586,  a  common  standard  format  for  UAV  control 
external  to  the  GCS,  can  be  realized.  Formats,  however,  are  not  limited  to  STANAG 
4586.  For  instance  the  Al.4.1  Control  Air  Vehicle  functional  block  receives  the 
proprietary  (e.g.  Boeing,  Northrop  Grumman,  etc.)  air  vehicle  commands  and  translates 
them  from  a  proprietary  air  vehicle  language  into  standard  formatted  commands  for  the 
air  vehicle.  This  translation  is  conducted  through  the  use  of  software  subroutines  that 
perform  the  translation  within  the  Control  Air  Vehicle  functional  block.  Similarly  the 
Al.4.2  Monitor  Air  Vehicle  functional  block  translates  the  common  standard  formatted 
air  vehicle  status  and  converts  it  to  the  native  system  language  within  the  GCS.  These 
two  translation  functional  blocks  allow  for  the  commonality  and  interoperability  that 
STANAG  4586  and  the  2009  USD(AT&F)  ADM  are  requesting. 

The,  Al.4.1  Control  Air  Vehicle  function  is  shown  in  Figure  39. 
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The  JUCCS  Control  Air  Vehicle  IDEFO  diagram  shows  the  functional  blocks  responsible  for  formatting  flight  parameters,  electrical  power  settings  and 
specific  avionics  equipment  settings  from  the  proprietary  language  into  a  common  standard  formatted  commands. 
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The  Al. 4.1  Control  Air  Vehicle  IDEFO  diagram  provides  further  deeomposition  of 
the  Control  Air  Vehicle  funetional  bloek.  The  Al.4.1.1  Control  Air  Vehicle  Flight 
Parameters  funetional  bloek  aeeepts  the  proprietary  air  vehiele  eommands  that  relate  to 
flight  parameters,  sueh  as  elimb  to  a  eertain  altitude  or  proeeed  to  a  certain  waypoint,  and 
translates  them  into  a  standard  STANAG  4586  formatted  flight  parameter.  The  Al.4.1.2 
Control  Air  Vehicle  Power  functional  block  accepts  the  proprietary  air  vehicle  commands 
that  relate  to  vehicle  power  management  and  translates  them  into  a  standard  STANAG 
4586  formatted  command.  An  example  of  this  functional  block  in  operation  is  turning 
off  the  external  lights,  radios  and  payload  power  in  the  event  of  an  emergency  generator 
failure  to  conserve  battery  power  for  flight  control  surface  movement  required  for  the 
emergency  landing.  The  Al.4.1.3  Control  Air  Vehicle  Equipment  functional  block 
accepts  the  proprietary  air  vehicle  commands  that  relate  to  equipment  settings  and 
translates  them  into  a  standard  STANAG  4586  formatted  command.  An  example  of  this 
functional  block  is  setting  the  IFF  codes  provided  by  ATC  or  changing  communications 
frequencies.  The  Al.4.1.4  Provide  Air  Vehicle  Interface  functional  block  accepts  the 
three  standard  STANAG  4586  formatted  commands  (flight  parameters,  power 
commands,  and  equipment  settings)  and  prioritizes  and  queues  these  commands  for 
transmission  to  the  air  vehicle  through  the  A1.7  Manage  Comms  &  Disseminate  Data 
functional  block. 


The  Ai. 4.2  Monitor  Air  Vehicle  function  is  shown  in  Figure  40. 


Figure  40.  JUCCS  IDEFO  A142  Monitor  Air  Vehicle 

The  JUCCS  Monitor  Air  Vehicle  IDEFO  diagram  performs  the  translation  of  the  input  standard  (such  as 
STANAG  4586)  formatted  air  vehicle  status  messages  and  translates  these  messages  to  the  native  system ’s 
proprietary  language  making  interoperability  possible.  The  link  status  is  also  monitored  for  usability. 
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The  Al.4.2  Monitor  Air  Vehicle  IDEFO  diagram  shows  the  two  functional  blocks 
that  monitor  the  air  vehicle  link,  telemetry  and  health.  The  Al. 4.2.1  Monitor  Air  Vehicle 
Link  Status  functional  block  receives  the  standard  STANAG  4586  formatted  status 
message,  checks  the  data  link  status  for  proper  operation,  and  then  translates  the  status 
message  into  the  proprietary  native  language.  The  Al.4.2. 2  Monitor  Air  Vehicle 
Telemetry  and  Health  functional  block  receives  the  standard  STANAG  4586  formatted 
air  vehicle  telemetry  and  health  status  message  and  translates  these  messages  to  the 
proprietary  native  language.  The  native  air  vehicle  telemetry  and  health  status  message  is 
then  queued  and  added  to  the  native  air  vehicle  data  link  status  and  disseminated  as 
native  air  vehicle  information  to  the  A1.3  Manage  Mission  functional  block. 

F.  SUMMARY  OF  JUCCS  ARCHITECTURE  AND  LINKAGE  TO 

REQUIREMENTS 

The  JUCCS  common  architecture  requirements  were  derived  in  Chapter  VI. B 
from  NAVAIR  program  and  other  UAS  documentation.  The  requirements  were 
tabulated  and  relationships  were  linked  from  the  JUCCS  common  architecture.  Each 
requirement  was  related  to  the  functional  architecture  in  order  to  trace  the  requirements 
of  the  system  to  the  initial  requirements  stated  in  the  ADM.  Table  9  shows  the 
requirements  linkage  to  the  functional  architecture. 
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Table  9.  Linkage  of  JUCCS  Architectural  Elements  to  Requirements 


This  table  shows  the  linkages  between  the  JUCCS  architectural  elements  and  the  requirements  that  were 
defined  earlier  in  the  report.  The  table  shows  that  some  of  the  requirements  are  directly  met  by  specific 
functional  blocks  while  others  are  indirectly  met  by  the  overall  methodology  used  in  the  architecture. 


Common  Architecture 
Requirement 

Linkage  to  JUCCS  Proposed  Common  Architecture 

1 .  The  Ground  Control 
Station  (GCS)  shall 
enable  Air  Vehiele 
Operator  (AVO) 
training  eommonality 
aeross  multiple 
Unmanned  Aireraft 
System  (UAS) 
platforms. 

Requirement  1  will  be  fulfdled  when  the  derived  requirements  2-5  are  satisfied. 

2.  The  Ground  Control 
Station  (GCS)  shall 
have  a  eommon 
Human-Maehine 
Interfaee  (HMI)  for 

Air  Vehiele  Operator 
(AVO)  flmetions. 

Funetion  Al.  1.4.2  Interfaee  w/  Air  Vehiele  Control  found  inside  of  Al.l 

Provide  Human  Interfaee  allows  the  arehiteeture  to  meet  requirement  2.  The 
interfaee  is  made  standard  through  a  single  AVO  interfaee  in  the  eommon  GCS 
arehiteeture.  This  will  allow  the  training  of  AVOs  of  different  UAS  air 
vehieles  in  a  single  way  of  entering  eommands  for  the  air  vehiele  into  the  GCS. 
This  means  a  single  type  of  training  ean  be  developed  and  AVOs  will  be  able 
to  operate  different  types  of  air  vehieles. 

3.  The  Ground  Control 
Station  (GCS)  shall 
allow  for  direeted 
viee  eontrolled  air 
vehiele  operation. 

Funetion  Al.l. 4.2  Interfaee  w/  Air  Vehiele  Control  allows  for  the  air  vehiele 
eontrols  to  be  designed  as  direeted  eontrols  so  that  they  are  eommon  from  air 
vehiele  to  air  vehiele.  Using  eontrolled  inputs  (flight  eontrol  stiek,  rudder  and 
throttles)  would  still  lead  to  differenees  in  how  eaeh  vehiele  was  given  inputs, 
but  by  being  a  direeted  eontrol  system,  all  the  eommands  ean  be  taught  the 
same  way. 

4.  The  Ground  Control 
Station  (GCS)  shall 
allow  for  separate 
Human-Maehine 
Interfaees  (HMI)  for 
payload  and  air 
vehiele  eontrol. 

The  strueture  of  A  1.1. 4  Interfaee  with  Mission  Management  Controls 
speeifieally  breaks  out  air  vehiele  eontrols  from  payload  eontrols.  It  is 
important  in  this  arehiteeture  that  the  air  vehiele  eontrol  be  isolated  from  the 
payload  eontrol.  Payloads  ean  vary  greatly  in  funetion  and  operation  from  air 
vehiele  to  air  vehiele  type.  The  AVO  eontrols  however  should  be  and  ean  be 
the  same,  and  this  separation  of  the  flmetions  beeomes  neeessary. 
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Table  9.  Linkage  of  JUCCS  Architectural  Elements  to  Requirements  (continued) 


Common  Architecture 
Requirement 

Linkage  to  JUCCS  Proposed  Common  Architecture 

5.  The  Ground  Control 
Station  (GCS)  shall 
have  a  eommon 
mission  planning 
system. 

Since  UAS  air  vehicles  require  a  mission  planning  system,  if  all  the  mission 
planning  systems  are  common  in  the  GCS,  then  a  single  way  of  training  for  use 
of  the  mission  planning  interface  can  be  utilized.  This  will  allow  for  all  AVO 
training  to  be  consolidated  into  a  standard  AVO  training  pipeline. 

6.  The  Ground  Control 
Station  (GCS)  shall 
enable 

interoperability 
between  multiple 
Unmanned  Airerafl 
Systems  (UASs). 

This  requirement  is  met  by  function  A1 .4  Command  and  Control  of  Air 

Vehicle.  This  function  allows  for  each  command  within  the  GCS  system  to  be 
translated  into  a  common  control  language  to  be  sent  to  the  air  vehicle.  This 
common  language  can  be  used  to  send  information  to  all  the  different  UAS  air 
vehicles  that  understand  the  common  language. 

7.  The  Ground  Control 
Station  (GCS)  shall 
enable  common 
communications  and 
data  link  management 
between  multiple 
Unmanned  Aircraft 
Systems  (UASs). 

Requirement  7  and  8  are  met  with  function  A1.7  Manage/Disseminate  Data  and 
A1.8  Perform  External  Comms.  These  functions  enable  physical  transport 
layer  and  encoding  layers  that  are  standard  between  vehicles.  They  also  allow 
for  a  standard  interface  that  can  be  trained  to  operators  in  common  training. 

8.  The  Ground  Control 
Station  (GCS)  shall 
utilize  a  common  data 
format  to  enable 
communication 
between  multiple 
manned  and 
unmanned  systems. 

Requirement  7  and  8  are  met  with  function  A1.7  Manage/Disseminate  Data  and 
A1.8  Perform  External  Comms.  These  functions  enable  physical  transport 
layer  and  encoding  layers  that  are  standard  between  vehicles.  They  also  allow 
for  a  standard  interface  that  can  be  trained  to  operators  in  common  training. 
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Table  9.  Linkage  of  JUCCS  Architectural  Elements  to  Requirements  (continued) 


Common  Architecture 
Requirement 

Linkage  to  JUCCS  Proposed  Common  Architecture 

9.  The  Ground  Control 
Station  (GCS) 
systems  software  and 
arehiteeture  shall  be 
modular  and  sealable. 

This  requirement  is  satisfied  by  the  separation  of  functions  in  the  architecture. 

This  will  allow  the  architecture  to  be  modular  and  scalable  to  different  number 
of  workstations.  The  software  can  follow  this  functional  architecture  allowing 
for  different  hardware  to  meet  the  functional  requirements  based  on  the 
operating  environment  and  the  need  of  the  GCS.  Each  GCS  can  then  be 
designed  independently  as  long  as  it  can  run  the  common  interface  software  so 
that  common  training  can  be  realized. 

10.  The  Ground  Control 
Station  (GCS)  shall 
enable  a  eommon 
approach  to  simplify 
support  and 
maintenance  across 
multiple  Unmanned 
Aircraft  System 
(UAS)  platforms. 

Because  the  software  can  be  designed  to  follow  the  common  architecture,  a 
single  set  of  software  can  be  used  for  the  AVO  control  and  interface.  This 
means  that  only  one  set  of  software  needs  to  be  updated  and  maintained.  This 
will  simplify  the  support  and  maintenance  by  reducing  multiple  software  suites 
that  need  maintenance  to  only  a  single  common  set  of  software. 

1 1 .  The  Ground  Control 
Station  (GCS)  shall 
enable  a  common 
approach  to  reduce 
the  manpower 
requirements  across 
multiple  Unmanned 
Aircraft  System 
(UAS)  platforms. 

Requirement  number  1 1  is  indirectly  satisfied  through  this  architecture  by  the 
fact  that  using  this  common  architecture  will  reduce  the  manpower  required. 

First,  because  of  common  training,  fewer  instructors  will  be  needed  to  train 
new  AVOs.  Secondly,  because  AVOs  can  fly  different  types  of  air  vehicles 
from  the  common  GCS,  AVOs  can  share  responsibilities  for  launch  and 
recovery  of  air  vehicles  as  well  as  be  used  to  help  fill  share  AVO  assignments. 

12.  The  Ground  Control 
Station  (GCS)  shall 
enable  a  common 
approach  to  minimize 
Unmanned  Aircraft 
System  (UAS) 
basing. 

Requirement  12  can  be  indirectly  met  because  with  a  common  GCS  and 
common  interfaces,  common  simulators  or  training  systems  can  be  utilized  on  a 
base.  This  reduces  the  number  of  different  kind  of  simulators  needed.  This  can 
reduce  the  number  of  bases  or  the  number  of  people  needed  to  maintain  the 
lower  number  of  simulators. 
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The  twelve  JUCCS  common  architecture  requirements  were  related  to  elements  of 
the  JUCCS  common  architecture.  The  functional  architecture  is  now  related  to  the 
derived  requirements,  which  in  turn  are  related  back  to  the  original  ADM  requirements. 
The  functional  architecture  is  also  traceable  to  elements  of  NAVAIR  and  DoD  UAS 
requirements.  The  requirements  and  architecture  are  the  basis  of  a  common,  modular, 
scalable  GCS  that  will  enable  common  AVO  training  across  multiple  UASs. 
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VIII.  IMPROVED  TRAINING  POSSIBILITIES  WITH  JUCCS 
COMMON  GCS  ARCHITECTURE 

The  current  DoN  UAS  AVO  training  concept  is  stovepiped  for  each  platform  and 
is  based  upon  the  existing  manned  platform  user  community.  Based  upon  JUCCS 
analysis  of  the  BUQs,  the  proposed  training  concept  is  for  common  AVO  training  across 
UAS  platforms.  Benefits  and  challenges  associated  with  the  common  AVO  training 
proposed  by  the  JUCCS  team  are  explored  in  this  section. 

A.  CURRENT  NAVY  UAS  TRAINING  PRACTICES 

1.  Navy  Training  System  Plans 

Developing  stovepiped  UAS  training  plans  may  be  the  simplest  option,  but  it  is 
probably  not  the  most  efficient  or  cost  effective  method  to  train  future  UAS  AVOs. 
BAMS  and  Fire  Scout  have  very  different  training  plans  and  STUAS  will  almost 
certainly  develop  its  own  unique  training  plan  when  the  program  reaches  that  point. 

As  part  of  the  Maritime  Patrol  and  Reconnaissance  Force  (MPRF)  Family  of 
Systems  (FoS),  the  BAMS  UAS  will  provide  a  multiple-sensor,  persistent  maritime  ISR 
capability,  as  an  adjunct  to  the  USN  P-8A  Poseidon  Multi-mission  Maritime  Aircraft 
(MMA)  weapons  system.  The  BAMS  UAS  supports  a  wide  variety  of  military 
operations.  They  include:  maritime  surveillance,  communications  relay,  homeland 
defense,  collection  of  enemy  order  of  battle  information,  mine  warfare,  maritime 
interdiction,  surface  warfare,  battle  damage  assessment,  counter  drug  operations,  port 
surveillance,  battlespace  management,  situational  awareness,  and  support  for  targeting  for 
maritime  and  littoral  strike  [PMA-205,  2007]. 

The  BAMS  UAS,  like  most  Group  3-5  UASs,  plans  to  transition  Naval  Aviators 
from  manned  platforms  to  fill  the  AVO  role.  Initially,  BAMS  UAS  operators  will  consist 
of  experienced  P-3C  Naval  Aviators  who  will  transition  directly  to  the  BAMS  UAS,  and 
provide  a  pool  of  experienced  operators.  In  the  future,  BAMS  UAS  operators  will  be 
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comprised  of  not  only  experienced  P-8A  Poseidon  aircrew,  but  may  also  include  initial 
accessions  not  exclusively  from  the  MPRF  community  as  shown  in  Figure  41. 

As  much  as  practical,  BAMS  UAS  training  media  and  delivery  will  emulate  P-8A 
Poseidon  and  other  UAS  FoS  approaches  to  ease  transition  training  and  provide  training 
standardization.  The  notional  BAMS  UAS  training  system  is  expected  to  include  formal 
schoolhouse  training  as  well  as  informal  training  (CBT  and  Web-Based  Training 
(WBT)),  a  Learning  Management  Information  System,  deployable  training,  embedded 
training,  and  training  devices  necessary  to  provide  the  most  effective  and  efficient 
training  system  [PMA-205,  2007]. 


Figure  41.  BAMS  Training  Pipeline 

The  pipeline  shows  the  training  required  for  a  BAMS  AVO  to  be  mission  qualified.  The  training  begins 
with  new  accessions,  and  ends  with  a  BAMS  squadron. 


Fire  Scout  is  a  USN  UAS  that  will  provide  a  Reconnaissance,  Surveillance,  and 
Target  Acquisition  (RSTA)  and  an  Intelligence,  Surveillance,  and  Reconnaissance  (ISR) 
and  communications  relay  capability  in  support  of  littoral  operations.  It  is  designed  to 
operate  as  part  of  a  Littoral  Combat  Ship  (LCS)  Aviation  Mission  Package  (AMP)  with 
support  being  focused  on  a  distributed  LCS  force  [PMA-205,  2008]. 

The  Fire  Scout  UAS  will  transition  MH-60  Naval  Aviators  to  fill  the  AVO  role. 
A  two-man  crew  will  operate  the  Fire  Scout  system.  The  crew  will  consist  of  a  Naval 
officer  AVO  or  MC  (Mission  Commander),  and  an  enlisted  Mission  Payload  Operator 
(MPO).  The  AVO  or  MC  will  be  dual-qualified  as  a  MH-60R/S  variant  helicopter  pilot 
and  as  a  Fire  Scout  operator.  The  training  pipeline  can  be  seen  in  Figure  42  on  the 
following  page. 
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Fire  Scout  training  courses  will  be  developed  in  accordance  with  Sharable 
Content  Object  Reference  Model  and  Integrated  Learning  Environment  requirements. 
The  training  will  be  provided  using  Interactive  Media  Instruction,  Interactive 
Courseware,  Computer-Aided  Instruction,  and  the  Fire  Scout  Mission  Training  Device 
(MTD)  [PMA-205,  2008], 


Figure  42.  Fire  Scout  Training  Pipeline 

The  pipeline  shows  the  training  required  for  a  Fire  Scout  AVO/MC  to  be  mission  qualified.  The  training 
begins  with  new  accessions,  and  ends  with  a  fleet  squadron  on  an  LCS. 


Both  the  Commander,  Naval  Surface  Forces  (CNSF)  and  Navy  Expeditionary 
Combat  Command  (NECC)  will  operate  STUAS  under  differing  organizational  and 
operational  constructs.  CNSF  will  operate  STUAS  through  ship-based  detachments.  The 
detachment  will  bring  all  necessary  equipment  to  operate  STUAS  from  a  ship  that  has 
been  modified  to  accommodate  the  UAS.  NECC  forces  within  the  Maritime 
Expeditionary  Security  Force  (MESF)  will  employ  STUAS  in  a  detachment  construct. 
The  MESF  plan  calls  for  a  detachment  in  each  Maritime  Expeditionary  Security 
Squadron  (MSRON).  MSRON  personnel  will  be  cross-trained  to  operate  some  or  all  of 
the  unmanned  vehicles  in  the  squadron,  to  include  air,  surface,  or  undersea  vehicles. 

Actual  STUAS  manpower  and  personnel  requirements  require  further  study  and 
refinement  based  on  training  programs  and  operational  experience.  CNSF's  initial 
manpower  estimates  indicate  that  a  detachment  size  of  five  personnel  is  required  to 
operate  STUAS.  The  current  MESF  plan  calls  for  a  six  man  detachment  in  each  of  the 
thirteen  MSRONs. 

STUAS  will  be  designed  to  be  operated  by  personnel  with  the  same  or  equivalent 
skill  levels  and  classifications  that  are  in  the  current  USN  active  duty  inventory,  but  this 
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does  not  imply  that  rated  aviators  are  required  or  desired  to  operate  the  air  vehicles  and 
sensor  payloads.  The  STUAS  training  system  is  expected  to  include  a  mix  of  instructor 
led  courseware,  CBT,  WBT,  and  scenario  based  crew  simulation  training. 

2.  Current  Navy  UAS  Training  Concepts 

BAMS  fleet  training  will  occur  at  one  of  the  Continental  United  States  (CONUS) 
BAMS  squadrons  which  may  be  co-located  with  P-3C  or  P-8A  Main  Operating  Bases 
(MOB).  The  BAMS  UAS  will  be  designed  with  an  integrated  full  mission  simulation 
capability,  which  will  be  capable  of  individual  and  crew  training  and  be  able  to 
participate  in  strike  group,  fleet,  and  joint  task  force  exercises  [USFFC,  2009].  While 
this  minimizes  the  number  of  unique  training  facilities  and  devices,  any  required 
modifications  would  be  fully  borne  by  the  BAMS  program. 

Helicopter  Sea  Combat  (HSC)  and  Helicopter  Maritime  Strike  (HSM)  squadrons 
support  a  variety  of  detachments  including  LCS  aviation  detachments.  Since  the  Fire 
Scout  AVO  and  MC  is  identified  to  come  from  the  MH-60  community,  the  schoolhouses 
are  conceptually  identified  to  be  co-located  with  fleet  concentration  areas  of  MH-60  to 
ease  training  travel  and  funding  issues.  Figure  43  illustrates  the  current  distribution  of 
MH-60  and  Fire  Scout  aviation  detachment  locations  [USFFC,  2009].  While  this  may 
make  Fire  Scout  training  more  convenient  for  the  squadron,  it  will  require  each  MH-60 
base  to  set  up  a  full  training  facility  for  all  operators  and  maintainers.  With  so  many 
unique  training  facilities  and  devices,  utilization  will  certainly  not  be  optimal  and  any 
required  modifications  would  be  fully  borne  by  the  Fire  Scout  program. 
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LCS  Configuration 
1AvDet=  23  personnel 
4  Officer/ 19  Enlisted 


HSCWLINORFOLKJ 
HSC-22  4 
HSC-26  4 
HSC-28  4 


HSCWP  (NASNh 
HSC-21  4 
HSC-23  4 


HSC-25  6  (GUAM) 
HSC-27  4  (ATSUGI) 
HSM-51  4  (ATSUGI) 


HSMWLBAYPORT) 
HSM42  8 
HSM-44  8 
HSM48  7 
HSM-60  4 


HSMWPXNASNI) 
HSM-35  8 
HSM49  5 


AvDel? 

0 

E 

Total 

West 

211 

84 

399 

483 

East 

39| 

156 

741 

897 

FDNF 

I4I 

56 

266 

322 

Total 

74* 

L_ 

1702* 

Note:  *  Personnel  for  training  and  staffs  not  shown. 


Figure  43.  MH-60  Fleet  Concentration  Areas 

This  illustrates  worldwide  concentration  of  MH-60/Fire  Scout  Aviation  Detachment  locations  and 
personnel  quantities.  Figure  from  [USFFC,  2009]. 


It  is  premature  to  discuss  the  current  STUAS  training  pipeline  since  the  program 
is  still  in  an  early  development  stage.  Actual  STUAS  manpower,  personnel,  and  training 
requirements  require  further  study  and  refinement  based  upon  future  training  programs 
and  operational  experience. 

Figure  44  illustrates  the  large  number  of  locations  where  training  is  currently,  or 
planned  to  be  performed,  and  the  training  devices  for  selected  UAS  platforms.  It  also 
highlights  an  inefficient  USN  and  U.S.  Marine  Corp  UAS  training  plan.  These 
inefficiencies  have  caused  PMA-205  to  propose  a  common  schoolhouse  for  future  UAS 
training  [PMA-205,  2009].  In  addition  to  the  common  schoolhouse  that  PMA-205  has 
proposed,  the  JUCCS  team  has  expanded  the  original  PMA-205  BUQ  analysis  in  order  to 
determine  if  a  common  GCS  architecture  combined  with  the  common  schoolhouse 
concept  can  realize  even  greater  gains  for  the  DoD. 
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MQ-8B  (FY15) 

MQ-SB  Maint  Trainer  (FY15) 


MQ-8B  T0FT(FY12) 

MQ-8B  Maint  Trainer  (FYIO) 


Fort  Huachuca,  AZ 

UAV  Systems  Training 
Center 

Shadow/ Hunter 

22  networked 
simuiators 

Eiectronic  Ciassrooms 


VMU-4 

Shadow  (IIMS) 


BAMS  =  Blue 
Fire  Scout=  Red 
Shadow  =  Gray 


MQ-8B  TOFT  (FY18) 


M0-8BTOFT  (FY17) 

M0-8B  Maint  Trainer  (FY17) 


5  Main  Operating  Bases  (MCS/MST) 

POR-5sites(2CONUS,  3  0C0NUS) 

BCA  Results:  shift  to  5  MCS  at  2  CONUS 
locations,  likely  NAS  J  AX  and  NAS  Wl 

Maintenance  Location  TBD 


NAS  Whidbey  Island,  WA 
MCS/MST 


TBD  (Yuma) 


MQ-8B  Maint  Trainer  (FY14) 


Figure  44.  Current  UAS  Training  Locations 

This  figure  illustrates  training  locations  for  selected  large  UASs.  Note  the  wide  distribution  of  training 

locations.  Figure  from  [PMA-205,  2009]. 


B.  PROPOSED  FUTURE  NAVY  UAS  TRAINING  PRACTICES 

PMA-205  has  proposed  a  common  schooLhouse  that  would  be  capable  of  common 
training  for  AVOs  based  upon  theb  analysis  of  the  BUQs.  Their  proposal  would  include 
a  common  core  curriculum  and  platform  centric  curriculum.  The  JUCCS  analysis 
expands  upon  the  PMA-205  analysis  and  addresses  the  BUQs  that  could  be  achieved 
through  the  proposed  architecture. 
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1.  Expanded  Analysis  of  Basic  UAS  Qualifications 


The  BUQ  I-IV  KSAs  are  the  foundation  for  the  design  and  implementation  of  the 
AVO  training  concept  of  operation.  As  described  previously  in  Chapter  V.C,  there 
currently  is  not  a  single  UAS  training  model  that  is  employed,  but  rather  disparate 
methods  at  decentralized  training  locations.  A  primary  theory  in  the  approach  to  this 
problem  was  that  overhead  costs  incurred  during  AVO  training  would  be  reduced  by 
implementing  a  common  GCS  architecture.  This  architectural  change  across  Group  3-5 
UASs  would  potentially  require  less  infrastructure,  reduced  manpower  requirements,  and 
a  single  course  of  instruction  for  primary  AVO  KSAs.  An  analysis  was  conducted  on  the 
BUQ  I-IV  KSAs  to  determine  if  a  quantifiable  benefit  could  be  realized. 

The  method  of  the  analysis  was  to  compare  the  BUQ  I-IV  KSAs  against  two  types 
of  GCS  architectures  across  Group  3-5  UASs.  Instructor  pilots,  operational  pilots,  and 
UAS  engineers  were  asked  to  assess  how  the  training  of  each  BUQ  could  be  conducted 
against  two  different  GCS  architectures.  A  score  of  common  was  to  be  awarded  if  the 
BUQ  training  was  common  across  all  the  UASs.  A  score  of  unique  was  to  be  awarded  if 
the  BUQ  training  was  deemed  to  be  unique  to  each  UAS.  If  one  stakeholder  deemed  a 
task  unique,  while  another  scored  it  common,  the  unique  scoring  was  awarded.  This  was 
done  to  create  the  most  conservative  comparison  possible. 

The  first  type  of  architecture  analyzed  was  labeled  the  As-ls  architecture.  The 
As-ls  represents  the  current  approach  to  UAS  GCS  architectures  where  there  is  no 
consideration  of  commonality  from  one  system  to  another.  The  second  type  of 
architecture  analyzed  was  the  JUCCS  Proposed  Common  GCS  Architecture.  The  JUCCS 
Proposed  Common  represents  a  common  GCS  architecture  implementation  across  all 
Group  3-5  UASs  as  proposed  in  this  project. 

Table  10  represents  a  sample  of  the  BUQ-III  KSA  analysis  raw  data.  As  an 
example,  for  the  Obtaining  an  IFR  clearance  KSA,  a  score  of  common  was  awarded  for 
both  architectures.  This  is  because  the  teaching  and  execution  of  this  task  is  not 
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dependent  on  the  interfaee  between  the  AVO  and  the  GCS.  The  IFR  elearanee  is  a 
proeedural  task  eondueted  prior  to  flight  operations  and  is  independent  of  any  interfaees. 
Conversely,  the  Establishing  and  maintaining  constant  altitude,  airspeed,  and  heading 
during  instrument  flight  KSA  was  seored  unique  in  relation  to  the  eurrent  HMI  employed, 
but  was  seored  common  based  upon  the  implementation  of  the  JUCCS  Proposed 
Common  GCS  Architecture.  In  this  example,  the  instruetion  to  teaeh  this  task  would 
require  platform  speeifie  training  based  upon  eurrent  system  design.  However,  the 
JUCCS  proposed  arehiteeture  with  a  eommon  HMI  interfaee  would  allow  this  task  to  be 
taught  exaetly  the  same  aeross  all  eandidate  platforms.  Table  10  shows  an  exeerpt  of  the 
BUQ  analysis,  while  the  eomplete  analysis  of  the  BUQs  ean  found  in  Appendix  D. 


Table  10.  Sample  of  Expanded  BUQ  Analysis  Based  on  Architecture  Type 

This  table  is  a  sample  of  the  expanded  BUQ  analysis  performed  by  the  JUCCS  team.  It  shows  whether 
specific  KSAs  would  need  to  be  taught  in  a  common  or  unique  manner  based  on  the  As-Is  or  JUCCS 

Proposed  Common  GCS  Architecture. 


BUQ 

Category 

KSA 

- ^ 

Training  with 
JUCCS  Proposed 
Common  GCS 
Architecture 

- ^ 

Training  with 
As-Is 

Unique  GCS 
Architectures 

III 

Aircraft  Operations 

Instrument  Flight 

Common 

Unique 

III 

III 

Aircraft  Operations 

Instrument  Flight  Procedures 

Common 

Unique 

Before  Flight 

Instrument  Flight  Rules  (IFR)  mission  planning 

Common 

Common 

III 

III 

III 

III 

III 

III 

III 

III 

III 

III 

Before  Flight 

Obtaining  an  IFR  clearance 

Common 

Common 

Before  Flight 

Operation  of  Air  Traffic  Surveillance  Equipment 
(IFF/SIF/TCAS/Sense  and  Avoid  Sensors) 

Common 

Unique 

Instrument 

Partial  panel  instrument  flight 

Common 

Unique 

Instrument 

Aircraft  maneuvers  under  instrument  conditions 

Common 

Unique 

Instrument 

Recognition  of  improper  nose  low  condition 

Common 

Unique 

Instrument 

Course  intercept 

Common 

Unique 

Instrument 

Rate  of  intercept 

Common 

Unique 

Instrument 

Angle  of  intercept 

Common 

Unique 

Instrument 

Recognition  and  recovery  from  unusual  attitudes  under 
instrument  conditions 

Common 

Unique 

Instrument 

Operation  of  aircraft  instruments  and  navigation 
equipment 

Common 

Unique 

III 

III 

III 

III 

III 

III 

Instrument 

Hazardous/adverse  weather  conditions  in  flight 

Common 

Unique 

Instrument 

Weather  phenomena  which  affect  flight 

Common 

Unique 

Instrument 

Establishing  and  maintaining  constant  altitude, 
airspeed,  and  heading  during  instrument  flight 

Common 

Unique 

Navigation 

Unfamiliar  field  departure  procedures 

Common 

Common 

Navigation 

Low  level  navigation 

Common 

Unique 

Navigation 

Unfamiliar  fiela  visual  and  instrument  approach 

procedures 

Common 

Common 
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The  results  of  the  analysis  for  BUQs  I-IV  are  shown  in  Table  11.  The  data  shows 
that  implementation  of  the  JUCCS  Proposed  Common  GCS  Architecture  will  reduce  the 
number  of  unique  training  tasks  from  154  out  of  213,  down  to  7  out  of  213  total  KSAs. 
These  seven  tasks  are  related  to  pre-flight,  post-flight,  and  emergency  procedures  specific 
to  the  different  airframes  of  the  UASs,  and  will  always  require  platform  specific  training. 
The  magnitude  of  the  reduction  of  unique  tasks  allows  the  consideration  of  a  common 
training  pipeline  for  AVOs,  which  could  result  in  tremendous  manpower,  infrastructure, 
and  cost  efficiencies. 

Table  11.  Reduction  of  Unique  KSAs  for  the  JUCCS  Proposed  Common  versus  As-Is  GCS 

Architectures 

This  table  shows  a  summary  of  the  expanded  BUQ  analysis.  The  number  of  unique  KSAs  that  need  to  be 
taught  at  each  BUQ  level  can  be  drastically  reduced  if  the  proposed  common  GCS  architecture  is  utilized. 


As-Is  GCS 
Architecture 

JUCCS  Proposed 
Common  GCS 
Architecture 

Total  KSAs 
per 

Architecture 

Common 

KSAs 

Unique 

KSAs 

Common 

KSAs 

Unique 

KSAs 

BUQ  I 

36 

68 

97 

7 

104 

BUQ  II 

13 

18 

31 

0 

31 

BUQ  III 

5 

14 

19 

0 

19 

BUQ  IV 

5 

54 

59 

0 

59 

TOTAL 

59 

154 

206 

7 

213 
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2.  Proposed  Common  Schoolhouse  Navy  UAS  Pipelines 


The  concept  of  a  common  UAS  schoolhouse  has  been  proposed  as  a  method  to 
increase  efficiency  in  the  training  methods  of  the  DoD.  This  idea  can  be  seen  in  the 
following  statement  made  by  the  UAS  Platform  Wholeness  CONOPS: 

In  order  to  ensure  standard  UAS  policy  and  procedures  and  gain  efficiency 
in  training  overhead  a  common  UAS  flight  school  or  UAS  school  house 
should  be  established  to  bridge  the  gap  between  accessions  programs  and 
type/model/series  (T/M/S)  specific  UAS  training  courses.  [USFFC,  2009] 

Driven  by  this  statement,  PMA-205  has  proposed  a  common  schoolhouse  concept.  Note 
that  this  concept  is  simply  to  geographically  consolidate  training  programs,  and  does  not 
rely  on  a  common  GCS  concept.  In  order  to  further  develop  the  possibilities  created  with 
a  combined  common  schoolhouse  and  a  common  GCS,  the  JUCCS  team  expanded  the 
BUQ  analysis  performed  by  PMA-205.  This  expanded  analysis  in  the  previous  section 
shows  that  the  number  of  unique  KSAs  for  each  BUQ  level  is  dramatically  reduced  by 
implementing  the  JUCCS  Proposed  Common  GCS  architecture. 

The  common  schoolhouse  concept  proposed  by  the  PMA-205  analysis  is  shown 
in  Figure  45.  It  shows  a  common,  core  schoolhouse  where  the  majority  of  the  UAS 
instruction  is  performed.  It  accommodates  new  accession  operators  with  a 
comprehensive  training  curriculum  as  well  as  previous  operators  with  platform  specific 
instruction.  Analysis  of  this  concept  shows  that  59  of  the  213  BUQ  I-IV  KSAs  could  be 
performed  using  common  training  with  the  remainder  requiring  platform  specific 
training.  It  is  important  to  note  that  this  concept  does  not  require  the  use  of  a  common 
GCS,  it  simply  consolidates  the  training  locations  with  the  current  unique  (As-Is)  GCSs. 
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Figure  45.  PMA-205  Notional  Operator  Training  Path 

This  diagram  shows  a  notional  training  path  that  would  result  from  implementing  a  common,  core 
schoolhouse  (but  not  a  common  GCS)  concept.  Note  that  154  KSAs  remain  platform  specific  and  need  to 
be  taught  outside  the  common  core  instruction.  Figure  from  [PMA-205,  2009]. 


If  the  common  GCS  concept  were  included  into  the  above  analysis,  improved 
capabilities  would  be  realized.  The  result  of  this  analysis  is  shown  in  Figure  46  on  the 
following  page.  It  is  very  similar  to  the  PMA-205  notional  operator  training  path,  but 
includes  more  commonality  based  upon  the  proposed  architecture  with  a  common  AVO 
interface.  The  JUCCS  analysis  shows  that  206  of  the  213  BUQ  I-IV  KSAs  could  be 
performed  using  common  training  with  only  seven  KSAs  requiring  platform  specific 
training.  These  seven  remaining  KSAs  are  airframe  specific  functions  related  to 
preflight,  post-flight,  and  emergency  procedures. 
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taught  at  Squadron 


Figure  46.  JUCCS  Notional  Operator  Training  Path 

This  diagram  shows  a  notional  training  path  that  would  result  from  implementing  a  common,  core 
schoolhouse  concept  with  JUCCS  proposed  common  architecture.  Note  that  only  seven  KSAs  need  to  be 
taught  outside  the  common  schoolhouse.  These  KSAs  are  airframe  specific  functions  related  to  preflight, 

post-flight,  and  emergency  procedures. 


3.  Quantitative  Benefits  Analysis  of  JUCCS  Proposed  Common  GCS 

To  compare  the  benefits  of  implementing  different  approaches  to  GCS 
architectures  and  AVO  training  methods,  the  JUCCS  team  created  a  notional  illustration 
to  compare  the  three  different  training  strategies  discussed  in  this  paper.  Since  STUAS  is 
still  in  source  selection  and  no  training  approach  has  been  defined,  Fire  Scout  and  BAMS 
were  the  only  existing  UASs  included  in  this  analysis  for  each  described  approach. 

The  first  comparison  item,  labeled  Option  1  in  Table  12,  consists  of  the  Aj'-A  GCS 
Architectures  with  Distributed  Schoolhouses.  This  concept  is  based  upon  existing  BAMS 
[PMA-205,  2007]  and  Fire  Scout  [PMA-205,  2008]  training  pipelines  and  documented 
training  CONOPS.  The  BAMS  and  Fire  Scout  GCS  architectures  for  this  concept  are  not 
common  as  they  represent  the  status-quo  of  the  respective  programs. 
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Option  2  in  Table  12  consists  of  the  As-ls  GCS  Architectures  with  Common 
Schoolhouse.  This  concept  is  based  upon  the  NAVAIR  Training  Systems  (PMA-205) 
co-located  training  model  discussed  earlier  in  this  paper  [PMA-205,  2009].  Although  this 
concept  includes  a  common  schoolhouse,  the  GCS  architectures  remain  unique  to  their 
respective  programs. 

Option  3  in  Table  12  consists  of  the  JUCCS  Proposed  Common  GCS  Architecture 
with  Common  Schoolhouse.  This  concept  is  based  upon  the  common  GCS  architecture 
proposed  by  JUCCS  in  this  project.  In  addition  to  providing  a  common  GCS 
architecture,  this  analysis  assumes  inclusion  of  the  common  schoolhouse  as  described  by 
PMA-205. 

To  lay  the  foundations  for  the  analysis  and  to  ensure  that  an  appropriate 
comparison  of  existing  and  notional  pipelines  was  completed,  the  following  assumptions 
were  employed: 

•  Analysis  is  based  upon  yearly  Operations  and  Sustainment  (O&S)  cost  of  the 
different  alternatives.  Historically,  O&S  costs  are  the  largest  component  of 
Life  Cycle  Costs  (LCC),  and  are  the  most  relevant  for  this  comparison.  The 
development  and  Military  Construction  (MILCON)  costs  of  the  notional 
alternatives  are  not  considered  in  this  analysis  as  they  are  a  very  small 
percentage  of  the  larger  LCC  over  a  20  year  operational  lifespan. 

•  AVO  throughput  is  assumed  constant  at  115  students  per  year.  This  is  the 
sum  for  the  current  documented  throughput  of  75  for  BAMS  [PMA-205, 
2007]  and  40  for  Fire  Scout  [PMA-205,  2008]. 

With  the  above  assumptions  made,  a  strategy  for  an  appropriate  analysis  can  be 
produced.  This  results  in  a  set  of  procedures  and  logic  that  are  detailed  in  Appendix  E. 
The  creation  of  this  logic  was  based  on  research  from  many  sources,  which  are  also  listed 
in  Appendix  E. 

The  assumptions  and  strategy  were  then  incorporated  into  the  O&S  cost  analysis 
displayed  in  Table  12.  The  O&S  cost  categories  include:  number  of  training  sites,  total 
number  of  simulators,  total  annual  simulator  O&S  cost,  total  annual  courseware 


147 


management  eost,  total  annual  infrastrueture  eost,  total  number  of  instructors,  total  annual 
instructor  cost,  total  number  of  support  and  administrative  personnel,  and  total  annual 
support  and  administrative  personnel  cost.  The  table  compares  the  cost  categories  for  the 
three  training  options. 

Option  2  is  included  in  the  analysis  because  it  is  an  intermediate  step  between  the 
As-Is  GCS  Architectures  with  Distributed  Schoolhouses  and  the  JUCCS  Proposed 
Common  GCS  Architecture  with  Common  Schoolhouse.  This  option  is  the  PMA-205 
proposed  common  schoolhouse  solution  with  no  common  GCS  architecture.  It  does  not 
realize  the  full  benefits  of  the  JUCCS  Proposed  Common  GCS  Architecture.  Therefore, 
the  following  discussion  of  the  analysis  will  focus  on  comparing  Option  1  to  Option  3. 

Several  observations  of  the  comparative  analysis  of  Option  1  and  Option  3,  found 
in  Table  12,  were  noted; 

•  A  common  schoolhouse  concept  reduces  the  number  of  training  sites  required 
ifom  7  to  1 

•  Required  number  of  simulators  decreases  ifom  14  to  4 

•  Annual  courseware  management  costs  using  a  common  architecture  are 
reduced  by  taking  advantage  of  a  96  percent  common  training  curriculum 

•  Total  annual  infrastructure  costs  are  reduced  as  the  number  of  sites  decreases 

•  The  number  of  instructors,  support,  and  administrative  personnel  is  reduced 
ifom  over  100  to  12 
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Table  12.  High  Level  Analysis  of  O&S  Costs  of  Different  Training  Options 


This  table  represents  the  notional  O&S  costs  of  the  current  and  proposed  training  concepts.  Note  the 
reduction  in  O&S  costs  as  the  level  of  commonality  increases. 


Option  1 

Option  2 

Option  3 

As-Is  BAMS 

with 

Distributed 

Schoolhouses 

As-Is  Fire 

Scout  with 

Distributed 

Schoolhouses 

Sum  of  As-Is  GCS 

Architectures  with 

Distributed 

Schoolhouses 
(BAMS  plus  Fire 
Scout) 

As-Is  GCS 

Architectures 

with  Common 

Schoolhouse 

JUCCS 
Proposed 
Common  GCS 

Architecture 

with  Common 

Schoolhouse 

Number  of 
training  sites 

2 

5 

7 

1 

1 

Total  number  of 

simulators 

4 

10 

14 

4 

4 

Total  annual 

simulator  O&S 

cost 

$2,124,000 

$5,310,000 

$7,434,000 

$2,124,000 

$2,124,000 

Total  annual 

courseware 

management 

$381,000 

$381,000 

$762,000 

$571,500 

$381,000 

Total  annual 

infrastructure  cost 

$231,200 

$578,000 

$809,200 

$231,200 

$231,200 

Total  number  of 

instructors 

12 

30 

42 

11 

8 

Total  annual 

instructor  cost 

$2,581,608 

$6,454,020 

$9,035,628 

$2,366,474 

$1,721,072 

Total  number  of 
support  and 
administration 
personnel 

18 

45 

63 

8 

4 

Total  annual 
support  and 
administration 
personnel  cost 

$2,353,392 

$5,883,480 

$8,236,872 

$1,045,952 

$522,976 

Total  annual 
training  O&S  cost 

$7,671,200 

$18,606,500 

$26,277,700 

$6,339,126 

$4,980,248 
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Several  eonelusions  of  the  eomparative  analysis  of  Option  1  and  Option  3  were 
noted.  The  total  annual  simulator  O&S  eost  deereases  by  over  $5  million.  Courseware 
management  costs  are  reduced  by  half  to  approximately  $318,000.  Total  annual 
infrastructure  costs  will  be  reduced  by  67  percent,  to  $231,000.  Total  annual  instructor 
cost  is  reduced  by  over  $7  million.  Total  annual  support  and  administration  personnel 
cost  is  reduced  by  94  percent  from  $8.2  million  to  $0.5  million.  The  total  annual  O&S 
cost  savings  is  projected  to  be  reduced  from  $26.3  million  to  $5.0  million.  Over  a  20 
year  period  the  LCC  savings  would  be  $426  million  in  current  year  dollars. 

C.  SUMMARY  OF  COMMON  UAS  TRAINING  BENEFITS 

It  is  clear  from  the  USD(AT&L)  ADM  that  Mr.  John  Young  believed  that  an 
opportunity  existed  to  maximize  training  efficiencies  by  implementing  a  common  UAS 
GCS  architecture  [USD(AT&L),  2009].  The  DoN  has  also  recognized  this  potential  and 
has  documented  it  in  the  Fleet  Unmanned  Aircraft  System  Platform  Wholeness  Concept 
of  Operations  [USFFC,  2009].  In  this  draft  document,  the  goals  of  Commander,  Fleet 
Forces  Command  for  the  DoN’s  UAS  FoS  are  discussed  and  include: 

The  Navy  will  efficiently  field  a  FoS  of  affordable  UASs  that  are  reliable 
and  supportable  in  both  Navy  and  USMC  environments  and  interoperable 
with  today’s  combat  systems.  The  FoS  approach  will  identify 
opportunities  for  commonality  that  can  provide  affordability,  flexibility, 
efficiency  and  greater  effectiveness.  These  opportunities  include,  but  are 
not  limited  to:  Commonality  among  UAS  operator  training  standards. 
Common  approaches  to  UAS  manpower  support  and  basing  needs... 
[USFFC,  2009] 

The  benefits  of  implementing  a  common  GCS  HMI  architecture  directly  support  these 
goals.  From  an  affordability  perspective,  the  reduced  need  for  infrastructure  is  the  largest 
factor  in  addressing  this  requirement.  By  implementing  an  architecture  that  allows  the 
majority  of  UAS  training  across  different  platforms  to  be  common,  one  can  also  lead  to 
the  ability  to  train  all  of  those  operators  at  a  single  location.  This  leads  to  a  reduced  need 
for  capital  investments  in  personnel  housing,  training  buildings,  classrooms,  support 
elements,  and  simulators.  It  also  allows  the  efficiency  desired  by  reducing  the  need  for 
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the  manpower  required  to  run  the  training  eenters.  Under  the  proposed  approach,  there  is 
a  reduced  need  for  the  number  of  instructors,  simulator  technicians,  courseware 
managers,  and  support  personnel.  Efficiencies  are  also  realized  by  increasing  the 
utilization  rate  of  the  facilities. 

The  benefits  of  implementing  a  common  GCS  architecture  still  hold  true  even  if 
the  DoN  elects  to  forgo  a  centralized  training  location.  Some  of  the  capital  benefits 
discussed  above  certainly  are  reduced,  however  instruction  could  still  be  standardized. 
This  leads  to  the  requirement  to  develop  a  single  core  syllabus  that  could  be  centrally 
managed. 

Another  benefit  of  implementing  the  common  architecture  is  that  the  time  to 
transfer  and  train  an  AVO  Ifom  one  UAS  to  another  is  significantly  reduced.  This  is  an 
added  benefit  to  implementing  the  common  architecture  with  common  AVO  HMI  and 
could  have  a  significant  impact  on  DoN  manpower  requirements  regardless  of  whether 
the  co-located  training  concept  is  implemented. 

D.  CHALLENGES  TO  IMPLEMENTING  COMMON  UAS  TRAINING 

Implementing  a  UAS  training  concept  with  co-located  training  brings  several 
potential  benefits  as  discussed  above,  however  there  are  some  concerns  that  deserve 
proper  attention.  They  range  Ifom  tangible  concerns  to  cultural  issues  that  should  be 
considered  prior  to  implementing  this  approach. 

A  primary  concern  is  that  there  are  vast  differences  between  the  larger  operational 
concepts  of  the  UASs  that  are  proposed  to  be  combined  into  a  single  training  pipeline. 
Flying  an  eight  hour  average  BAMS  mission  is  much  different  than  executing  a  two  hour 
average  Fire  Scout  mission.  If  one  considers  the  pure  difference  in  size  between  these 
two  UASs,  and  the  fact  that  one  is  a  fixed-wing  UAV  while  the  other  is  a  rotary-wing 
UAV,  it  becomes  apparent  that  challenges  exist.  The  argument  is  if  the  status-quo  of 
separate  training  locations  remains,  the  new  AVOs  would  be  trained  by  instructors  who 
most  likely  are  past  operators  of  the  same  system,  or  at  least  fully  immersed  in  the  single 
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system,  and  are  likely  to  tailor  the  training  experienee  toward  real  world  operations.  In 
the  proposed  eombined  training  eoneept,  one  eould  have  a  Fire  Seout  instruetor  teaehing 
a  BAMs  operator  how  to  eonduet  a  landing  approach.  If  the  proposed  architecture  is 
implemented  correctly,  it  should  not  matter,  but  it  is  a  concern  that  must  be  addressed. 

There  are  also  benefits  to  conducting  training  at  the  operational  bases  of  the  UASs 
vice  at  a  separately  located  training  center.  This  is  less  tangible,  but  there  is  a  benefit  in 
having  access  to  actual  fleet  AVOs  during  training.  They  provide  a  good  source  of 
knowledge  and  also  are  generally  good  critics  of  the  quality  of  instruction  that  is  being 
provided.  They  also  are  used  to  provide  training  to  students,  which  may  be  lost  if  the 
training  center  was  not  co-located  with  the  operational  units. 

Finally,  if  a  common  training  center  approach  was  implemented,  the  individual 
program  offices  of  the  UASs  under  development  would  have  to  implement  integrated 
approaches  toward  training.  This  would  require  each  PMA  to  relinquish  total  authority 
for  training  (as  is  implemented  today)  and  establish  a  forum  to  employ  common  training. 
This  would  add  requirements  to  the  programs  that  would  impact  the  budgets  of  the 
current  PMAs  since  some  of  their  training  funding  would  be  ported  to  a  common  training 
program  office. 
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IX.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSIONS 

The  JUCCS  team  eondueted  researeh  to  determine  the  plausibility  of 
implementing  eommonality  in  UAS  GCSs,  and  the  potential  benefits  that  could  be 
attained  by  achieving  such  commonality.  The  team  focused  on  the  GCS  since  this  is  a 
necessary,  but  often  overlooked  portion  of  the  overall  system.  Additionally,  the  ADM 
released  by  USD(AT&L)  in  2009  directed  that  commonality  be  implemented  in  UAS 
GCSs. 


To  scope  the  problem,  the  JUCCS  team  concentrated  on  creation  of  a  GCS 
functional  architecture  that  enabled  common  AVO  training.  The  AVO  functions  were 
chosen  because  they  are  similar  from  UAS  to  UAS,  while  payload  functions  (weapons 
and  sensors)  can  vary  greatly  between  systems.  Training  was  selected  as  a  focus  because 
it  was  specifically  cited  in  the  ADM  as  a  potential  benefit  from  GCS  commonality.  The 
scoped  problem  was  then  used  to  answer  the  research  questions  posed  by  the  team  at  the 
beginning  of  the  project: 

Research  Question  1.  What  is  meant  by  common  and  what  is  this  project’s 
interpretation  of  common? 

At  a  basic  level,  common  means  that  some  aspect  of  a  system  is  shared  with  another 
system.  This  can  include  hardware,  software,  or  data  link  languages  in  a  UAS.  This 
project  interprets  common  to  mean  that  two  or  more  UASs  share  an  aspect  that  will  add 
functional,  operational,  or  logistical  advantage  to  the  systems. 

Research  Question  2.  Is  there  a  link  between  commonality  and  interoperability? 

The  analysis  showed  that  commonality  and  interoperability,  while  sometimes  used 
interchangeably,  are  two  different  concepts.  Discussions  included  the  notion  that 
commonality  and  interoperability  can  be  achieved  independently  from  each  other.  It  was 
shown  that  commonality  is  possible  without  interoperability,  and  interoperability  is 
possible  without  commonality.  Achieving  the  goals  stated  in  the  2009  ADM  require 
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some  level  of  both  commonality  and  interoperability  for  UASs.  In  general,  some  amount 
of  commonality  is  typically  required  to  realize  a  level  of  interoperability  between 
systems.  JUCCS  Proposed  Common  GCS  Architecture  facilitates  commonality  for  the 
GCS  and  enables  interoperability  between  UAS  platforms. 

Research  Question  3.  Is  it  possible  to  achieve  some  level  of  commonality  for 

UAS  GCSs,  and  if  so,  what  requirements  are  necessary? 

The  analysis  completed  in  this  project  shows  that  it  is  possible  to  achieve  some  level  of 
commonality  for  UAS  GCSs.  While  this  has  not  happened  frequently  in  the  past,  it  is 
possible  for  future  acquisitions. 

In  order  to  facilitate  common  AVO  training  to  the  maximum  extent,  the  JUCCS 
analysis  showed  that  a  common  HMI  for  AVO  functions  is  necessary.  The  common 
HMI  concept  requires  a  directed  type  interface  where  the  flight  parameters  (airspeed, 
altitude,  latitude,  longitude,  etc)  are  input,  as  opposed  to  a  controlled  type  interface  where 
piloting  devices  (flight  sticks,  throttle,  rudder,  etc)  are  utilized.  This  type  of  HMI 
commonality  does  not  exist  for  current  systems. 

Analysis  of  BUQs  showed  that  there  were  no  common  standards  for  AVO 
training  and  qualifications.  Additionally,  requirements  for  UAS  commonality  were  not 
present  in  any  DoN  programs  examined.  The  following  twelve  system  requirements 
were  determined  to  be  necessary  to  achieve  common  AVO  training  and  the  other 
functions  required  by  the  DoN  UAS  community: 

Requirement  1.  The  Ground  Control  Station  (GCS)  shall  enable  Air  Vehicle 

Operator  (AVO)  training  commonality  across  multiple  UAS  platforms. 

Requirement  2.  The  Ground  Control  Station  (GCS)  shall  have  a  common 

Human-Machine  Interface  (HMI)  for  Air  Vehicle  Operator  (AVO)  functions. 

Requirement  3.  The  Ground  Control  Station  (GCS)  shall  allow  for  directed  vice 

controlled  air  vehicle  operation. 

Requirement  4.  The  Ground  Control  Station  (GCS)  shall  allow  for  separate 

Human-Machine  Interfaces  (HMI)  for  payload  and  air  vehicle  control. 
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Requirement  5.  The  Ground  Control  Station  (GCS)  shall  have  a  eommon 
mission  planning  system. 

Requirement  6.  The  Ground  Control  Station  (GCS)  shall  enable  interoperability 
between  multiple  Unmanned  Air  Systems  (UASs). 

Requirement  7.  The  Ground  Control  Station  (GCS)  shall  enable  eommon 
communieations  and  data  link  management  between  multiple  Unmanned  Air 
Systems  (UASs). 

Requirement  8.  The  Ground  Control  Station  (GCS)  shall  utilize  a  common  data 
format  to  enable  communication  between  multiple  manned  and  unmanned 
systems. 

Requirement  9.  The  Ground  Control  Station  (GCS)  systems  software  and 
architecture  shall  be  modular  and  scalable. 

Requirement  10.  The  Ground  Control  Station  (GCS)  shall  enable  a  common 
approach  to  simplify  support  and  maintenance  across  multiple  Unmanned  Air 
System  (UAS)  platforms. 

Requirement  11.  The  Ground  Control  Station  (GCS)  shall  enable  a  common 
approach  to  reduce  the  manpower  requirements  across  multiple  Unmanned  Air 
System  (UAS)  platforms. 

Requirement  12.  The  Ground  Control  Station  (GCS)  shall  enable  a  common 
approach  to  minimize  Unmanned  Air  System  (UAS)  basing. 

In  order  to  be  effective,  these  requirements  would  need  to  be  mandated  for  future 
acquisition  programs.  This  list  of  requirements  alone  is  not  enough  to  create  an  actual 
common  system,  and  leads  to  the  next  research  question; 

Research  Question  4.  To  meet  these  requirements,  what  architectural 
characteristics  need  to  be  developed? 

From  these  requirements  the  JUCCS  Proposed  Common  GCS  Architecture  was 
developed.  This  architecture  fulfills  the  commonality  desired  in  the  ADM.  The  primary 
characteristic  modeled  was  an  independent  HMI  function  for  interacting  with  the  AVO. 
The  functional  architecture  was  developed  to  be  both  modular  and  scalable.  The  air 
vehicle  control  function  was  designed  to  be  a  single  interoperable  format  that  would  be 
used  by  all  future  UAVs  to  communicate  with  the  common  GCS. 
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Research  Question  5.  What  are  some  of  the  benefits  and  challenges  of  achieving 

UAS  GCS  commonality? 

Using  the  JUCCS  Proposed  Common  GCS  Architecture,  an  expanded  analysis  was 
performed  against  the  BUQs.  It  was  shown  that  implementing  the  JUCCS  architecture 
would  allow  for  common  AVO  training  in  all  areas  except  those  that  are  related  to 
specific  UAV  airframes  (pre-flight,  post-flight,  and  emergency  procedures).  A  brief 
analysis  was  performed  to  show  an  example  of  monetary  savings  that  could  be  achieved 
by  using  the  JUCCS  architecture  through  reduction  in  instructors,  training  devices,  and 
system  and  software  maintenance.  The  analysis  showed  a  potential  cost  savings  of  over 
$400  million  in  O&S  costs  for  training  aspects  of  the  GCS  common  architecture  over  a 
20  year  span.  This  quantification  did  not  include  potential  benefits  other  than  those 
found  in  training  and  additional  benefits  can  be  expected  when  other  logistical  elements 
are  analyzed. 

Additionally,  some  of  the  challenges  related  to  a  common  GCS  architecture  were 
explored.  These  challenges  relate  to  the  differing  missions  of  the  UASs  affecting  the 
common  schoolhouse  concept.  UAS  program  offices  would  also  lose  some  of  the 
autonomy  they  currently  have  due  to  the  need  for  a  separate  common  GCS  program 
office. 


In  summary,  the  JUCCS  project  has  developed  a  set  of  key  requirements 
necessary  for  the  creation  of  a  common  GCS  architecture.  These  requirements  were  used 
to  create  the  innovative  JUCCS  Proposed  Common  GCS  Architecture  with  a  common 
AVO  HMI.  This  approach  facilitates  common  training  for  UAS  AVOs.  In  addition  to 
increasing  operational  capability,  the  common  GCS  architecture  also  facilitates 
interoperability.  The  common  GCS  architecture  provides  additional  benefits  of  reducing 
training  O&S  costs  and  ensuring  consistent  UAS  AVO  training. 

B.  RECOMMENDATIONS 

To  enable  the  common  GCS  architecture,  it  is  recommended  that  changes  be 
made  to  the  existing  NAVAIR  acquisition  process.  Currently,  entire  systems  are 
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procured  through  a  single  program  offiee.  For  traditional  aireraft  and  weapons  with  a 
single  main  airframe  this  works  well.  In  the  world  of  UASs,  there  are  two  major  system 
eomponents,  the  UAV  and  the  GCS.  Presently,  both  the  UAV  and  GCS  are  proeured 
together  through  one  program  office.  This  is  the  traditional  model  for  aequisition  at 
NAVAIR. 

Some  activities  of  hardware  or  software  that  are  shared  between  programs,  sueh 
as  the  Joint  Mission  Planning  System  (IMPS),  are  implemented  by  a  separate  program 
offiee  that  is  responsible  for  the  maintenanee,  support,  and  eonfiguration  management  of 
the  system.  The  IMPS  program  offiee  has  eontrol  over  the  software,  ean  set  some 
speeifieations  on  the  hardware  that  is  needed  to  run  it,  and  provides  all  the  interfaee 
doeuments  to  the  individual  programs  that  are  going  to  use  the  software. 

The  method  reeommended  by  the  JUCCS  team  to  implement  a  eommon  GCS  is 
to  establish  a  separate  program  office  for  the  eommon  GCS.  To  allow  the  eommon  GCS 
to  remain  modular  and  scalable,  the  eommon  GCS  program  office  would  eontrol  the 
arehiteeture  and  software  of  the  GCS.  The  AVO  software  could  be  kept  standardized  by 
utilizing  a  eommon  HMI  module  speeffieally  for  AVO  funetions.  This  would  enable 
eommon  AVO  training  between  multiple  platforms. 

Payload  eontrol  software  eould  also  be  kept  as  separate  modules  and  libraries  of 
speeifie  software  subroutines  for  eontrolling  various  types  of  payloads.  If  a  program 
needed  to  develop  a  new  type  of  interfaee,  both  for  data  transfer  and  HMI,  then  those  new 
subroutines  eould  be  added  to  the  eommon  payload  library  for  use  by  new  systems  or  for 
upgrading  older  ones. 

Eaeh  program  offiee  for  a  new  UAS  would  be  responsible  for  the  new  UAV  and 
its  eapabilities.  The  UAS  program  offiee  would  also  be  responsible  for  the  physieal 
hardware  and  layout  of  the  GCS.  This  would  allow  the  programs  to  seale  the  GCS 
hardware  to  the  system  requirements.  Some  large  UASs  may  require  a  larger  GCS  erew, 
sueh  as  the  six  planned  for  BAMS.  Other  UASs  may  require  two  or  fewer  operators. 
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The  UAS  program  office  could  scale  the  operator  stations  to  those  necessary  for  the 
system.  This  ability  would  allow  the  use  of  different  hardware  based  on  the  operating 
environment  of  the  GCS.  A  ship  based  GCS  may  require  hardware  (antennae,  computers, 
etc)  that  are  hardened  against  water  and  salt.  An  aircraft  based  GCS  may  need  a  trackball 
that  can  remain  stationary  at  a  workstation  while  the  aircraft  maneuvers. 

The  individual  UAS  program  offices  would  coordinate  with  the  common  GCS 
program  office  to  effectively  transfer  the  government  furnished  software  and  work  with 
the  UAV  prime  contractor  to  make  the  necessary  hardware  and  software  changes  to  meet 
the  common  GCS  levels  of  commonality  and  interoperability.  This  would  be  analogous 
to  the  way  the  IMPS  program  office  currently  conducts  business  with  other  entities 
within  NAVAIR. 

Once  the  common  GCS  program  office  is  operational,  it  would  be  necessary  for 
NAVAIR  to  mandate  a  requirement  that  the  common  GCS  architecture  be  used  by  all 
new  DoN  UAS  programs.  This  mandatory  requirement  would  ensure  the  level  of 
commonality  needed  to  implement  and  sustain  common  AVO  training. 

C.  AREAS  FOR  FURTHER  STUDY 

The  JUCCS  team  limited  the  scope  of  this  research  to  the  very  specific  area  of 
commonality  in  the  GCS  and  how  it  would  relate  to  AVO  training.  From  the  generated 
architecture  and  the  results  of  the  training  analysis,  other  areas  of  study  can  be 
recommended  for  follow  on  research: 

1.  A  cost  benefit  analysis  of  the  effect  the  commonality  and  interoperability  the  JUCCS 
architecture  would  have  on  the  ten  elements  of  logistics  is  recommended.  This  research 
could  further  examine  the  cost  and  time  savings  realization  on  manpower  requirements, 
basing,  personnel  assignments  and  training,  etc.  as  discussed  in  Chapter  III.D. 

2.  An  analysis  and  design  of  a  standardized  common  AVO  HMI  is  recommended.  While 
this  report  showed  the  benefit  of  using  a  common  AVO  HMI,  actual  functions  and  how 
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they  would  be  designed  for  operator  interaction  needs  to  be  defined.  This  would  include 
the  software  functional  architecture  and  the  actual  physical  architecture  for  the  software 
user  interface  as  well  as  the  relative  layout  of  the  displays  and  audio  and  tactile 
information  for  the  AVO.  This  effort  would  need  to  include  the  requirements  of  displays 
and  their  relative  positions  to  each  other.  Implementation  of  input  devices  would  need  to 
be  discussed  as  well  as  other  operator  interaction  requirements. 

3.  Design  of  an  interoperable  air  vehicle  command  and  control  module  used  by  the 
common  GCS  for  sending  AVO  commands  is  recommended.  This  effort  would  require  a 
gap  analysis  to  look  at  STANAG  4586  and  compare  it  to  the  needs  of  current  DoN 
programs.  If  STANAG  4586  were  found  to  be  insufficient  to  meet  the  AVO  functions  of 
the  common  GCS,  a  new  standard  for  DoN  UASs  would  need  to  be  developed. 

4.  Further  analysis  of  the  internal  and  external  data  link  and  communications  for  the 
JUCCS  functional  architecture  is  recommended.  This  would  lead  to  an  expansion  of  the 
JUCCS  architecture  to  lower  levels  in  the  internal  and  external  communications 
functions.  These  new  functions  could  then  be  analyzed  for  design  of  the  physical 
architecture.  This  design  would  need  to  examine  both  LOS  and  OTH  communications. 
Existing  systems  would  need  to  be  explored  to  see  if  they  could  be  used  to  facilitate  the 
functions  of  the  architecture. 

5.  Investigation  of  common  payload  HMI  functions  is  recommended.  The  payload  HMI 
and  functionality  was  specifically  excluded  from  the  JUCCS  architecture.  Because  the 
payloads  can  vary  so  greatly  from  one  UAV  to  another,  a  common  approach  to  payloads 
was  not  explored.  Further  research  could  be  conducted  on  possible  functional  modules 
for  both  sensors  and  payloads.  This  research  could  be  the  basis  for  a  payload  control  and 
HMI  library  in  a  common  GCS  program. 
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1.0  INTRODUCTION 

This  is  the  Capstone  Project  Management  Plan  (PMP)  for  the  Naval  Air  Systems 
Command  (NAVAIR)  Cohort  #1,  hereto  after  referred  to  as  the  Joint  Unmanned  Aircraft  (or  Air) 
Systems  (UASs)  Common  Control  Station  (JUCCS)  team.  As  part  of  the  Naval  Postgraduate 
School  (NPS)  Master  of  Science  in  Systems  Engineering  (MSSE)  Capstone  Project,  the  JUCCS 
team  will  investigate  and  evaluate  the  potential  for  commonality  among  UAS  Ground  Control 
Stations  (GCSs)  as  outlined  in  this  document  and  per  the  memorandum  delivered  to  the  cohort 
(NPS,  May  2009). 

1.1  Project  Description 

The  current  generation  of  unmanned  aircraft  systems  (UASs)  have  been  in  development 
for  defense  applications  since  the  1980’s  (GAO,  April  2006).  Commonalities  among 
subsystems,  payloads,  and  ground  control  stations  have  not  yet  been  attained  (GAO,  July  2009). 
This  lack  of  commonality  is  seen  not  only  between  service-specific  UASs,  but  also  between 
Department  of  the  Navy  (DON)  acquired  UASs.  DON  UASs  are  currently  developed  with 
unique  GCSs.  The  primary  focus  of  each  of  these  GCSs  has  been  to  assist  in  the  flight 
operational  capabilities  of  the  air  vehicle  or  the  control  and  operation  of  the  onboard  sensor  suite. 
Minimal  attention  has  been  paid  to  the  design  of  the  ground  station  other  than  what  has  been 
required  to  meet  basic  air  vehicle  functionality.  Additionally,  the  design  requirements  for  the 
GCSs  have  been  determined  predominately  by  each  air  vehicle  vendor.  Therefore,  as  more 
systems  are  being  acquired  by  the  DON,  the  population  and  variety  of  GCS  equipment  has  begun 
to  proliferate  with  little  regard  for  commonality  in  hardware,  software,  training  and  logistics. 

The  Under  Secretary  of  Defense  for  Acquisition,  Technology  and  Logistics  (USD 
(AT&L)),  Mr.  John  J.  Young,  Jr.,  recognized  this  critical  and  timely  issue  during  a  program 
review  in  late  2008.  In  a  1 1  Feb  2009  Acquisition  Decision  Memorandum  (ADM)  to  the 
Secretaries  of  the  Army,  Navy  and  Air  Force,  Young  states:  “the  acquisition  team  has  the 
opportunity  to  do  something  truly  joint  and  powerful  by  adopting  a  common  GCS  architecture 
that  is  open  and  thus  will  allow  for  rapid  addition  of  modular  functionality”  (USD(AT&L), 
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February  2009).  He  continues  in  the  same  ADM  to  direct  steps  to  be  taken,  including  “initiate  a 
joint  efFort  to  develop  and  demonstrate  a  common,  open  and  scalable  UAS  architecture. . . ” 

In  July  2009  the  U.S  Government  Accountability  Office  (GAO)  released  a  written  report 
to  the  Subcommittee  on  Air  and  Land  Forces,  House  Armed  Services  Committee  that  provides 
more  insight  into  Mr.  Young’s  direction.  The  GAO  states  that  “taking  an  open  systems 
approach  and  designing  systems  with  common  subsystems  and  components  can  reduce  both 
production  and  life  cycle  costs  as  well  as  improve  interoperability  among  systems...  Unmanned 
aircraft  systems  can  potentially  achieve  commonality  in  design  and  development..  .  as  well  as 
commonality  in  production  facilities,  tooling,  and  personnel”  (GAO,  July  2009).  The  GAO 
concluded  that  “DoD  officials  have  not  quantified  the  potential  costs  or  benefits  of  pursuing 
various  alternatives,  including  systems  with  commonalities”  (GAO,  July  2009). 

To  begin  filling  this  void  where  no  quantifiable  data  exists,  this  project  proposes  to 
identify  areas  of  UAS  (jCS  commonality  as  directed  by  the  USD  (AT&L)  ADM.  This  project 
will  focus  its  investigation  on  the  GCSs  that  are  currently  in  operation,  development,  and 
planning  stages  by  the  DON  as  described  in  the  Unmanned  Systems  Integrated  Roadmap 
(USD(AT&L),  April  2009).  The  JUCCS  team  will  define  and  evaluate  modular  and  open 
architecture  opportunities  of  common  GCS  hardware,  software,  and  logistical  elements.  A 
systems  engineering  (SE)  approach,  as  described  in  Section  2.0,  will  be  utilized. 

1.2  Problem  Statement 

The  lack  of  1)  common  standards,  2)  design  for  modularity,  and  3)  open  system 
specifications  has  resulted  in  the  problem  of  unique  GCSs  for  each  DON  UAS,  increasing 
acquisition  expenses,  training  requirements,  and  logistics  footprints.  The  Department  of  Defense 
(DoD)  has  been  directed  to  develop  a  plan  to  add  commonality  to  UAS  programs  since  the  DoD 
cannot  continue  to  develop,  sustain,  and  operate  UASs  founded  on  stand-alone,  propriety 
architectures.  In  the  absence  of  any  quantifiable  evidence,  Mr  Young  has  stated,  and  the  GAO 
has  concluded,  that  a  common  GCS  for  UASs  may  yield  benefits  to  the  common  logistics 
elements  of  training  and  maintenance. 
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1.3  Project  Proposal 

This  capstone  project  will  analyze  the  command  and  control  (C2)  architecture  for  current 
and  new  acquisition  of  Groups  2  through  5  DON  UASs  (non-man-portable)  in  order  to  optimize 
the  benefits  of  GCS  commonality  for  training,  manpower,  basing  and  logistics  support.  The  goal 
of  this  analysis  is  to  inform  decision  makers  on  the  benefits  and  risks  associated  with  designing 
commonality  into  GCSs.  In  support  of  this  goal  interviews  will  be  conducted  with  subject  matter 
experts  and  case  studies  will  be  examined. 

The  expectation  of  this  research  is  to  identify  potential  areas  of  commonality  that  future 
GCS  acquisitions  can  leverage  for  more  effective  acquisition  programs.  The  systems 
engineering  architecture  and  framework  for  common  GCSs  may  yield  potential  benefits 
including  common  logistics  elements  of  training,  maintenance  and  sustainment. 

1.4  Organization 

The  JUCCS  team  organization  is  provided  in  Figure  1-1.  The  areas  of  responsibilities 
within  the  team  organization,  defined  as  Integrated  Product  Teams  (IPTs),  were  chosen  to 
optimize  the  success  of  the  capstone  project. 
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Figure  1-1.  JUCCS  Team  Organization 

This  chart  shows  the  JUCCS  team  organization  structure.  The  Project  Manager  is  shown  at  the  top  of  the  hierarchy 
with  the  individual  IPTs  reporting  upward. 
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1.4.1  Roles  &  RespnnsihUitics 

The  JUCCS  team  consists  of  12  interdisciplinary  team  members  located  in  the 
vicinity  of  Naval  Air  Station  Patuxent  River,  Maryland.  All  team  members  have  acquisition 
experience  from  working  within  the  competencies  or  Program  Offices  of  NAVAIR. 

Assigning  the  Project  Manager  role  was  based  on  three  key  elements:  1)  UAS 
knowledge,  2)  leadership  ability,  and  3)  understanding  of  systems  engineering  (SE)  principles. 
Once  this  critical  position  was  selected  and  approved  by  the  JUCCS  team  members,  the  JUCCS 
IPTs  were  assigned  to  individual  team  members. 

A  student  knowledge  assessment  tool  was  used  to  assist  with  the  roles  and 
responsibilities  within  the  IPTs.  This  tool  allowed  each  team  member  to  assess  his/her  strengths 
and  weaknesses  in  both  SE  topics  (e  g.,  human  factors,  cost  analysis,  etc.)  and  software  program 
tools  (e  g.,  CORE,  ExtendSim,  etc.)  and  was  used  to  aid  in  placing  each  member  in  an 
appropriate  IPT.  An  example  of  the  student  knowledge  assessment  tool  can  be  seen  in  Table  1-1. 
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Table  l-l.  Student  Knowledge  Assessment  Tool 

The  student  knowledge  assessment  tool  was  used  to  evaluate  the  strengths  and  weaknesses  of  the  project  members. 
This  ex’aluation  was  then  used  by  the  group  to  properly  place  individuals  within  the  IPT  structure. 


Note;  Be  honest  in  describing  your  strengths  and  weaknesses.  For  Example:  If  you  have  never  used  CORE  or 
EXTENDSIM,  then  you  should  rank  them  in  the  0-2  ranking.  If  you  did  all  of  the  ExtendSim  projects  by  yourself 
and  feel  that  you  are  awesome  doing  that,  then  you  should  be  in  the  9-10  category. _ 


1.4.2  Roles  anil  ResponsihUities  Defined 

Project  Manager  (PM):  Responsible  for  managing  all  IPTs  within  the 
organizational  structure  of  the  capstone  project.  He/She  will  make  executive  decisions  at  times 
when  matters  are  not  agreed  upon  by  the  team  members.  He/She  will  be  the  primary  point  of 
contact  between  the  project  advisors,  external  stakeholders,  and  the  capstone  team  members. 

Requirements  IPT  (RIPT):  Responsible  for  compiling  requirements  documents 
from  existing  Navy  UAS  programs  in  support  of  a  requirements  and  constraint  analysis.  The 
analysis  from  the  RIPT  will  aid  the  Architecture  IPT  with  direction  for  the  common  architecture 
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Architecture  IPT  (AlPT):  Responsible  for  defining  and  implementing  the  JUCCS 
architecture  by  using  the  DoD  Architecture  Framework  (DoDAF)  version  1.5  as  the  primary 
reference.  Tasking  includes  creation  of  an  upper  level  Concept  of  Operations  (CONOPS), 
functional  decomposition  and  proposed  functional  architecture.  The  architecture  team  members 
will  use  the  CORE  software  package  as  their  primary  tool. 

Project  Management  IPT  (PMIPT):  Responsible  to  assist  the  PM  in  all  project 
management  efforts  to  include  schedule  generation  and  compilation  of  document  deliverables 
and  includes  the  following  roles: 

•  Editors  (EDR):  Responsible  for  the  proper  editing  of  all  document  deliverables. 
They  are  responsible  for  every  document  deliverable’s  configuration  control  and 
administration. 

•  BlackBoard  Administrators  (BBAdm):  Responsible  for  the  administration  of  the 
capstone  project’s  BlackBoard  website.  They  will  manage  the  website  in  an 
efficient,  presentable,  and  organized  manner  to  allow  for  clear  communications 
and  data  exchange  among  team  members. 

•  Project  Scheduler  (PS):  Responsible  for  maintaining  the  capstone  project’s 
Master  Project  Schedule.  Fle/She  will  also  maintain  a  master  schedule  that 
consists  of  each  team  member’s  work  schedule  and  time  away  from  the  office. 

Logistics  IPT  (LIPT):  Responsible  for  assessing  potential  benefits  of 

implementing  the  common  architecture  designed  by  the  Architecture  IPT  The  assessment  will 
include  benefits  that  can  be  expected  from  a  logistical  (training)  standpoint.  Tasking  includes 
development  of  appropriate  metrics,  meetings  with  stakeholders  and  performing  an  Analysis  of 
Alternatives  (AoA) 

1.4.3  JUCCS  Team  Member  Assignments  and  Responsibilities 

The  initial  placement  of  each  team  member  can  be  seen  in  Figure  1-2.  The  roles 
and  responsibilities  are  subject  to  change  as  the  project  progresses. 


6 


173 


JUCCS  Project  Management  Plan 


Figure  1-2.  Individual  Assiguments  to  the  IPT  Groups 

This  figure  shows  the  assignments  of  all  individuals  within  the  IPT  structure  chosen  for  the  JUCCS  project. 


1.4.4  Project  Advisors 

The  JUCCS  team  advisors  are  Dr.  Richard  Millar,  Mr.  Gregory  Miller,  and 
Captain  John  Schmidt.  Dr.  Millar  and  Mr.  Miller  are  NPS  faculty  members  in  the  Department  of 
Systems  Engineering.  Captain  Schmidt  is  a  NPS  adjunct  faculty  member  and  is  assigned  to  the 
Naval  Air  Systems  Command  (NAVAIR). 

1.4.5  Stakeholders 

The  following  organizations  have  some  part  in  the  UAS  development  process  or 
are  involved  in  the  design,  management,  production,  and  maintenance  of  the  systems.  They  are 
grouped  into  three  categories:  resource  sponsor,  acquisition  community,  and  user  community. 

Stakeholders  will  be  contacted  for  information  during  the  development  of  the 
JUCCS  project.  The  stakeholders  will  be  asked  to  give  briefs,  share  documents,  and  be 
interviewed  in  order  to  retrieve  relative  information  for  this  study.  This  information  will  be 
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reviewed  and  incorporated  in  the  analysis  of  the  common  GCS  problem.  Since  there  is  currently 
no  overriding  regulations  on  commonality  between  GCSs,  the  JUCCS  team  will  identify  any 
misalignments  between  the  various  stakeholders. 

Additional  stakeholders  may  be  identified  by  the  JUCCS  team  as  research 
progresses.  These  additional  stakeholders  will  be  added  as  necessary  and  the  JUCCS  team  will 
addresses  their  concerns,  as  applicable. 

1.4.5.1  Resource  Sponsor 

•  Office  of  the  Chief  of  Naval  Operations,  Air  Warfare  Division 
(OPNAV  N88  or  N88):  OPNAV  N88  responsibility  is  to  validate 
and  resource  Research,  Development,  Test  and  Evaluation 
(RDT&E)  and  aircraft  procurement  for  the  USN. 

1.4.5.2  Acquisition  Community  (NAVAIR,  August  2009): 

•  Program  Executive  Office  Unmanned  Aircraft  and  Weapons  (PEO 
(U&W)):  The  PEO  (U&W)  will  expeditiously  develop,  acquire, 
and  support  quality  air  to  ground  strike  weapons,  unmanned  aerial 
vehicles,  and  target  systems  with  which  the  operating  forces,  in 
support  of  our  Unified  Commanders  and  allies,  can  train,  fight,  and 
win. 

•  PEO  U&W  Common  System  Integration  Team  (PEO  (U&W) 
CSl):  Organization  stood  up  by  PEO  (U&W)  to  facilitate  a  larger 
integration  of  common  systems  within  USN  UAS  programs. 

•  Naval  Air  Systems  Command  (NAVAIR):  NAVAIR  provides 
unique  engineering,  development,  testing,  evaluation,  in-service 
support,  and  program  management  capabilities  to  deliver  airborne 
weapons  systems  that  are  technologically  superior  and  readily 
available.  Using  a  full-spectrum  approach,  the  command  delivers 
optimal  capability  and  reliability  for  the  Sailor  and  the  Marine.  All 
of  the  UAS  program  offices  are  sub-groups  of  NAVAIR. 
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•  Naval  Air  Warfare  Center  Aircraft  Division  (NAWCAD): 
NAWCAD  provides  engineering  and  business  development  of  new 
aircraft  systems  in  support  of  NAVAIR. 

•  PMA-262:  The  Persistent  Maritime  Unmanned  Aircraft  Systems 
Program  Office  (PMA-262)  was  established  to  manage  the 
development,  production,  fielding,  and  sustainment  of  all  persistent 
maritime  unmanned  aircraft  systems.  Programs  that  currently  fall 
under  the  cognizance  of  PMA-262  include  the  Broad  Area 
Maritime  Surveillance  (BAMS)  UAS  and  the  BAMS  Demonstrator 
programs. 

•  PMA-263:  The  Small  Tactical  Unmanned  Air  System  Program 
Office  (PMA-263)  is  responsible  for  the  management  of 
developing,  producing,  and  sustaining  small  UASs.  The  office 
currently  also  runs  the  Scan  Eagle  Intelligence,  Surveillance,  and 
Reconnaissance  (ISR)  services  contract. 

•  PMA-266:  PMA-266  is  the  Program  Office  for  Multi-Mission 
Tactical  UAS.  The  program  office  has  cognizance  over  the 
Vertical  Takeoff  and  Land  Tactical  Unmanned  Aerial  Vehicle 
(VTUAV),  commonly  known  as  Fire  Scout.  The  program  office  is 
also  responsible  for  the  emerging  area  of  Air  Launched  UASs, 
poised  to  transition  this  developmental  capability  to  a  production 
fleet  capability. 

•  PMA-268:  Navy  Unmanned  Combat  Air  System  Program  Office 
(PMA-268)  is  currently  managing  the  demonstration  program  for 
an  Unmanned  Combat  Air  System  (UCAS).  The  program’s  goal  is 
to  demonstrate  the  feasibility  of  aircraft  carrier  operations  for  an 
unmanned  system. 

•  USN  Operational  Test  and  Evaluation  Force  (OPTEVFOR):  As 
the  sole  independent  agent  for  Operational  Test  and  Evaluation 
(OT&E)  in  the  Navy's  acquisition  process,  OPTEVFOR  conducts 
OT&E  in  a  realistic  operational  environment.  OPTEVFOR  also 
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advises  the  Chief  of  Naval  Operations  (CNO)  on  the  operational 
effectiveness  and  suitability  of  new  and  improved  war  fighting 
systems  and  capabilities,  tactics,  and  procedures. 

•  Naval  Test  Wing  Atlantic:  Located  at  Patuxent  River  Naval  Air 
Station,  the  air  wing  is  comprised  of  various  test  squadrons 
responsible  for  developmental  testing  of  unmanned  systems. 

•  Production  Contractors:  Various  companies  that  design  and  build 
UASs  for  the  Navy.  A  common  GCS  will  change  the  way 
companies  conduct  business. 

•  U  S.  Air  Force:  The  largest  Department  of  Defense  (DoD)  group 
currently  developing  and  fielding  UASs.  The  Air  Force  is 
currently  looking  at  ways  of  increasing  commonality  between 
systems.  The  Air  Force  has  a  parallel  structure  for  development 
and  fielding  of  UASs. 

1.4.5.3  User  Community 

•  Combatant  Commander  (COCOM):  The  field  users  of  the  UASs. 

1.5  Approach  for  PMP  Updates 

The  JUCCS  PMP  is  a  living  document  that  provides  the  framework  for  project  execution 
and  completion.  As  such,  it  will  be  updated  throughout  the  project  lifecycle  as  necessary.  At  a 
minimum,  it  will  be  updated  once  prior  to  the  final  brief  Minor  updates  to  the  PMP  such  as 
schedule  and  organizational  changes  will  be  coordinated  through  the  JUCCS  project  advisors  for 
approval.  Major  changes  to  the  PMP,  to  include  major  scope  changes  to  the  project,  or  any 
change  deemed  appropriate  by  the  project  advisors,  will  require  the  approval  of  the  Chair  of  the 
NPS  Systems  Engineering  Department.  Once  changes  are  approved  at  the  appropriate  level,  the 
PMP  will  be  updated,  and  a  record  of  the  change  will  be  documented  at  the  beginning  of  the 
PMP 
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1.6  Configuration  Management 

The  deliverables  created  by  the  JUCCS  team  are  planned  to  be  in  the  form  of  documents, 
presentations,  architectures  and  analyses.  The  Editors  will  maintain  a  copy  of  all  deliverables 
and  deliverable  revisions  in  a  chronological  archive.  The  JUCCS  team  will  revise  each  of  the 
deliverables  as  necessary  prior  to  being  finalized  for  submittal.  The  JUCCS  team  edits  will  be 
tracked  utilizing  a  system  of  incremental  alphabetical  revisions  (e  g.,  PMP  Rev  A  to  PMP  Rev 
B).  Once  a  deliverable  is  ready  for  submittal  it  will  be  published  utilizing  numeric  revision  (e  g., 
PMP  Rev  1). 

1.7  Interim  Project  Reviews  (IPR) 

The  JUCCS  team  will  employ  interim  project  reviews  (IPRs)  to  ensure  accuracy,  validity, 
and  appropriateness  of  the  project  objectives  and  requirements.  Capstone  work  products  will  be 
reviewed  by  the  JUCCS  team,  its  advisors,  and  project  stakeholders  to  ensure  all  parties 
understand  the  problem,  the  approach  and  the  proposed  solution.  Two  IPRs  will  be  conducted 
during  the  project's  timeline.  The  IPRs  will  assess  the  validity  of  the  problem  identification  and 
analysis.  They  will  also  assess  the  technical  quality  and  depth  of  proposed  solution.  During  the 
IPRs,  the  project  team  will  test  assumptions,  review  stakeholder  inputs  and  confirm  with  project 
advisors  that  adequate  SE  rigor  has  been  applied  to  the  defined  problem. 

1.8  Final  Report  and  Brief 

The  final  report  will  provide  details  of  the  SE  process  applied  to  the  problem  statement 
defined  by  the  JUCCS  team.  It  will  include  conclusions  and  recommendations  on  potential  areas 
of  commonality  for  GCSs  A  pre-brief  of  the  final  presentation  will  be  given  to  the  academic 
advisors  followed  by  the  final  brief  to  NPS  and  the  stakeholders.  The  final  brief  will  provide  the 
executive  summary  to  include  conclusions  and  recommendations.  The  planned  outline  of  the 
final  report  is  shown  below; 
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2.0  SYSTEMS  ENGINEERING  APPROACH 

The  systems  engineering  approach  will  guide  the  methodology  used  by  the  JUCCS  team 
throughout  the  project.  This  approach  will  be  modified,  as  required,  to  ensure  it  is  consistent 
with  the  current  objectives  for  the  project. 

2.1  Overview 

The  systems  engineering  process  the  JUCCS  team  will  employ  is  a  tailored  approach  to 
the  process  discussed  in  Systems  Engineering  Principles  and  Practice  (Kossiakoff  &  Sweet, 
2003). 

The  higher  level  systems  engineering  process  that  is  discussed  in  this  reference  can  be 
seen  in  Figure  2-1.  This  process  describes  three  phases  of  systems  engineering  as  Concept 
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Development,  Engineering  Development  and  Post  Development.  For  the  purposes  of  the  JUCCS 
project,  much  of  the  work  will  be  contained  in  the  Concept  Development  and  Engineering 
Development  phases. 


Figure  2-1.  Generic  Systems  Engineering  Process  (Kossiakoff  &  Sweet,  2003) 


This  figure  shows  the  generic  systems  engineering  process  that  iim  taihreil for  the  JUCCS  project.  The  process 
shows  phases  of  Concept  Development,  Engineering  Development  and  Post  Development. 


The  generic  systems  engineering  process  was  then  tailored  specifically  for  the  JUCCS 
project  The  tailored  process  can  be  seen  in  Figure  2-2.  This  process  is  divided  into  the  four 
phases  of  Information  Gathering  and  Problem  Definition,  Concept  Development,  Engineering 
Development,  and  Design  Recommendations  and  Conclusions. 

The  process  begins  with  Information  Gathering  and  Problem  Definition.  Once  the 
problem  has  been  defined,  the  iterative  phase  of  Concept  Development  commences.  This 
iteration  continues  until  an  initial  functional  architecture  has  been  defined  that  satisfies  critical 
functional  requirements.  Next,  the  Engineering  Development  iterates  until  a  final  functional 
architecture  has  been  defined  that  meets  detailed  requirements  based  on  stakeholder  feedback. 
Lastly,  the  Design  Recommendations  and  Conclusions  are  produced.  Problem  scoping  and 
stakeholder  feedback  loops  are  utilized  throughout  the  process  as  shown  in  Figure  2-2. 
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2.2  Information  Gathering  and  Problem  Definition 

There  are  currently  no  statutory  or  funded  Navy  requirements  for  a  common  UAS  GCS. 
The  1 1  February  2009  Memorandum  from  the  Under  Secretary  of  Defense  for  Acquisition, 
Technology,  and  Logistics  (USD(AT&L),  February  2009),  calls  for  “adopting  a  common  DoD 
architecture  utilizing  a  core  open  architecture  model.”  However,  this  document  does  not  levy 
any  specific  requirements.  As  part  of  this  project  the  JUCCS  team  will  define  different  levels  of 
requirements  for  various  levels  of  commonality.  Possible  definition  and  requirement  suggestions 
will  be  identified  during  the  problem  definition  phase  of  this  project  and  documented 
accordingly.  Additionally,  existing  systems  will  be  researched  to  provide  an  adequate 
background  for  further  studies  during  the  information  gathering  phase 

2.3  Problem  Scoping 

After  the  information  gathering  phase,  an  initial  scoping  of  the  problem  will  occur.  This 
problem  scoping  will  be  iterative  with  the  concept  development  phase  to  ensure  the  objectives  of 
the  program  are  achievable  in  the  timeframe  allowed. 

2.4  Concept  Development 

In  the  concept  development  phase,  the  JUCCS  team  will  perform  a  stakeholder  needs 
analysis  to  determine  the  requirements  and  priorities  of  the  stakeholders.  The  initial  step  will  be 
to  ensure  the  correct  set  of  stakeholders  has  been  identified.  The  team  will  then  elicit  the 
stakeholders’  requirements  and  priorities  potentially  affected  by  GCS  commonality. 
Requirements  and  constraints  will  then  be  defined  and  analyzed  in  relation  to  the  defined 
problem  statement.  Use  cases  may  be  developed  to  assist  with  defining  the  common  GCS 
architecture. 

The  JUCCS  team  will  perform  an  analysis  of  alternatives  for  current  functional  and 
physical  GCS  architectures  to  determine  functional  capabilities  and  requirements  for  current 
UAS  GCS  systems.  A  gap  analysis  will  be  performed  to  identify  gaps  between  the  stakeholders’ 
elicited  requirements  and  those  of  current  GCS  systems.  An  initial  functional  analysis  of  legacy 
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GCS  architecture  will  be  performed  to  identify  all  the  critical  functional  requirements  for 
common  GCSs.  This  functional  analysis  will  yield  an  initial  functional  architecture,  but  the 
functional  analysis  will  not  attempt  to  define  a  physical  architecture  for  a  common  GCS. 

2.5  Engineering  Development 

A  decision  making  process  will  be  required  to  determine  if  an  existing  GCS  architecture 
can  be  utilized  to  perform  the  proposed  common  GCS  functions,  if  an  existing  GCS  architecture 
meets  the  defined  common  functional  requirements,  it  will  be  adopted  for  the  JUCCS  team  use. 
If  no  existing  GCS  architecture  can  be  adopted,  the  JUCCS  team  will  design  a  new  common 
GCS  functional  architecture  as  a  final  deliverable.  This  functional  architecture  will  not  produce 
a  physical  architecture  for  a  common  GCS. 

2.6  Design  Recommendations  /  Conclusions 

The  final  action  in  the  defined  systems  engineering  process  will  utilize  information  from 
the  preceding  phases  to  formulate  recommendations  on  the  future  application  of  the  proposed 
common  GCS  architecture  to  the  stakeholders. 

The  final  recommendations  will  include:  a  common  GCS  functional  architecture,  a 
process  for  implementing  the  architecture  and  a  qualitative  assessment  of  the  benefits  that  could 
be  realized  by  utilizing  a  common  GCS  framework. 

The  final  recommendations  will  not  include  a  detailed  cost  benefit  analysis. 

2.7  Tools 

A  toolset  of  software  programs  will  aid  the  JUCCS  team  throughout  this  project. 
Architecture  development  and  SE  functions  will  be  documented  and  managed  with  Vitech’s 
software  program  CORE  Scheduling  will  be  accomplished  with  Microsoft  Project.  Modeling 
and  simulation  (as  required)  will  utilize  Microsoft  Excel  and  ExtendSim.  Word  processing  and 
presentation  materials  will  utilize  the  Microsoft  Office  suite  of  products. 
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As  the  JUCCS  project  progresses,  the  toolset  will  be  reevaluated  to  ensure  compatibility 
with  current  program  needs.  New  tools  will  be  added  as  required  to  fulfill  project  objectives. 


2.8  Risk  Management 


Risks  to  the  JUCCS  project  will  be  documented  and  managed  as  they  become  known. 
Where  necessary,  a  risk  matrix  as  shown  in  Figure  2-3  will  be  used  to  communicate  risks  to  the 
project  advisors.  All  attempts  will  be  made  to  properly  scope  the  problem  to  avoid  project  risks. 
Risks  that  cannot  be  avoided  will  be  the  responsibility  of  the  program  management  IPX  for 
appropriate  mitigation. 


Risk  will  be  managed  in  accordance  with  the  Risk  Management  Guide  for  DoD 
Acquisition  (NAVAIR,  January  2008). 


Level 

Likelihood 

Probability  of  Occurence 

1 

Not  Likelv 

-10% 

2 

Low  likelihood 

-30% 

3 

bkely 

-50% 

i 

Hiohlv  likelv 

-70% 

5 

Near  Certain 

-90% 

1  2  3  4  5 

Consequence 


Level 

Schedule 

1 

Minimal  or  no  impact 

2 

Additional  activities  required,  able  to  meet  key  dates 

Slip  <2  weeks 

3 

Minor  schedule  slip,  no  impact  to  key  milestones. 

Slip  <  1  months  plus  available  float  of  critical  path 

4 

Program  cntical  path  affected,  ail  schedule  float  associated  with  key 
milestone  exhausted. 

Slip  <2  months 

5 

Cannot  meet  key  program  milestones 

Slip  >  2  months 

Figure  2-3.  Sample  DoD  Risk  Matrix  Format,  based  on  (NAVAIR,  January  2008) 

The  DoD  risk  matrix  shows  risks  as  a  likelihood  vs.  consequence  per  the  specification  lahles.  The  likelihood  and 
consequences  are  defined  on  the  left  side  of  the  figure,  while  the  ri.sks  are  located  on  the  risk  matrix  in  the  upper 

right  portion  of  the  figure. 
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2.8.1  Risks 

The  JUCCS  team’s  current  risks  are  listed  below  and  will  be  continually 
evaluated  and  updated  as  appropriate. 

5 

■S’* 

o 

:S3 

1 

12  3  4  5 

Consequence 

Figure  2-4.  JUCCS  Project  Current  Risks 

Thi.s  risk  matrix  shows  the  curreni  risks  associated  with  the  JUCCS  program.  The  risk  matrix  will  he  updated  as 

new  ri.sks  are  discovered. 

Risk  1:  JUCCS  Team  Will  Not  Produce  Deliverable  by  March,  2010  (L2,  C3) 

•  Description  of  risk:  If  the  JUCCS  team  does  not  produce  a  final  deliverable  by  March 
2010,  then  master’s  degrees  are  not  conveyed  on  time. 

•  Statement  of  cause:  The  JUCCS  team  must  properly  scope  the  objective  and  achieve 
a  sound  technical  baseline  from  which  to  manage  tradeoffs  and  project  solutions 
within  the  allotted  timeframe. 

•  Consequence  if  risk  is  realized:  Exit  criteria  for  MSSE  program  will  not  be  conveyed 
on  time. 

2.8.2  Issues 

Any  risk  that  is  realized  becomes  an  issue  and  will  be  focused  on  separately  to 
minimize  the  effects. 
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3.0  DELIVERABLES  AND  SCHEDULE 

The  JUCCS  program  deliverables  and  schedules  are  defined  per  this  section.  The 
schedule  will  be  continuously  updated  as  the  project  progresses. 

3.1  IPRs  and  Deliverables 

Table  3-1  lists  each  IPR  and  milestone  associated  with  the  JUCCS  project.  The 
stakeholders  and  the  JUCCS  team  must  agree  that  the  required  deliverable(s)  are  completed 
satisfactorily  before  an  IPR  is  considered  complete 

3.2  Schedule 

The  schedule  for  the  JUCCS  project  is  provided  in  Figure  3-1 . 
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Table  3-1.  List  of  IPRs  and  Deliverables. 

The  listing  of  program  deliverables  is  shown  in  this  table.  These  deliverables  were  extracted from  the  original 
problem  statement  provided  to  the  team  by  the  .\’PS  ach’isors. 


DeUverahle 

Number 

Description 

Deliverable 

Date 

Pre-IPR  1 

PMP  Approval 

Project  Management  Plan 

3  Sep  2009 

IPR  1 

Problem  Background 

24  Sep  2009 

Iiifornialion  Gathering  tUtd  Problem  Definition 

a. 

Elements  Influencing  Commonalit> 

Written  Description  of  Elements 

24  Sep  2009 

b. 

Areas  Impacted  by  Commonality 

Written  Description  of  Impacts 

24  Sep  2009 

c. 

Scoped  Problem 

Project  Problem  Statement 

24  Sep  2009 

IPR  2 

Iterative  Systems  Engineering 
Process 

17  Dec  2009 

Concept  Development 

a. 

Stakeholder/Necds  Analysis 

Report  of  Needs  Analy  sis 

17  Dec  2009 

b. 

Requirements  and  Constraints  Analy  sis 

Report  of  Requirements  and 
Constraints 

17  Dec  2009 

c. 

Analy  sis  of  Altematives  of  Current 
Operational  Arcliitccturc 

Report  of  Altemativ  es  and 
Architecture 

1 7  Dec  2009 

d. 

Functional  Analy  sis 

Report  of  Functional  Analy  sis 

17  Dec  2009 

Engineering  Dev  elopment 

a. 

Requirements  Clarification 

Detailed  Requirements 

17  Dec  2009 

b. 

Updated  Functional  Analy  sis 

Functional  Analy  sis 

17  Dec  2009 

c. 

Functional  Arcliitecture 

Functional  Arcliitecture 

17  Dec  2009 

Final  Report 

Report  Delivery  &  Project 
Presentation 

25  Mar  2010 

a. 

Design  Recommendations 

Design  Recommendations 

25  Mar  2010 

b. 

Project  Summary 

Project  Summary 

25  Mar  2010 
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4.0  ACRONYMS 

Acronym 

Term 

ADM 

Acquisition  Decision  Memorandum 

BAMS 

Broad  Area  Maritime  Surveillance 

C2 

Command  and  Control 

CAIV 

Cost  as  an  Independent  Variable 

CNO 

Chief  of  Naval  Operation 

DoD 

Department  of  Defense 

DON 

Department  of  Navy 

GAO 

Government  Accountability  Office 

GCS 

Ground  Control  Station 

INCOSE 

International  Council  on  Systems  Engineering 

IPR 

Interim  Project  Reviews 

IPT 

Integrated  Product  Team 

ISR 

Intelligence,  Surveillance,  and  Reconnaissance 

JCIDS 

Joint  Capabilities  Integration  Development  System 

JUCCS 

Joint  UAS  Common  Control  Station 

MSSE 

Masters  of  Systems  Engineering 

NAVAIR 

Naval  Air  Systems  Command 

NPS 

Naval  Postgraduate  School 

OPTEVFOR 

Operational  Test  and  Evaluation  Force 

OT&E 

Operational  Test  and  Evaluation 

PEO 

Program  Executive  Office 

PM 

Program  Manager 

PMP 

Project  Management  Plan 

R&M 

Reliability  and  Maintainability 

RDT&E 

Research,  Development,  Test  and  Evaluation 

SE 

Systems  Engineering 

STANAG 

Standard  Agreement 

U&W 

Unmanned  Aviation  and  Weapons 

UAS 

Unmanned  Air  or  Aircraft  (or  Air)  Systems 
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Acronym 

UAV 

UCAS 

USD  (AT&L) 
VTUAV 


Term 

Unmanned  Aerial  Vehicle 
Unmanned  Combat  Air  Systems 

Under  Secretary  of  Defense  of  Acquisition,  Technology,  and  Logistics 
Vertical  Take-off  and  Land  Tactical  UAV 
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APPENDIX  C:  DEFINITION  OF  AIRSPACES 


FL  600 


•Class  A:  Generally,  airspace  from  18,000  feet  mean  sea  level  (MSL)  up  to  and  including  flight  level  (FL)  600  (i.e.  60,000  ft.) 

•Class  B:  Generally,  airspace  from  the  surface  to  10,000  feet  MSL  surrouhding  the  nation’s  busiest  airports. 

•Class  C:  Generally,  airspace  from  the  surface  to  4,000  feet  above  the  airport  elevation  (charted  ih  MSL)  surrounding  those  airports  that  have  an  operational 
control  towrer,  are  serviced  by  a  radar  approach  control,  and  have  a  certain  number  of  IFR  operations. 

•Class  D:  Generally,  that  airspace  from  the  surface  to  2,500  feet  above  the  airport  elevation  (charted  in  MSL)  surrounding  those  airports  that  have  an 
operational  control  tower. 

•Class  E:  Generally,  if  the  airspace  is  not  Class  A,  B,  C,  or  D,  and  is  controlled  airspace,  then  it  is  Class  E  airspace. 

•Class  G:  Airspace  not  designated  as  Class  A,  B,  C,  D,  or  E.  Class  G  airspace  is  essentially  uncontrolled  by  ATC  except  when  associated  with  a  temporary 
cohtrol  tower. 

•Chart  and  words  from  Federal  Aviation  Administration  (FAA)  document  number  FAA-H-8083-15A,  Instrument  Flying  Handbook,  2008  chapter  8 
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APPENDIX  D:  COMPLETE  BUQ  ANALYSIS 


BUQ 

Category 

KSA 

- ^ 

Training  with 
common 

HMI 

Training  with 
Current 
interfaces 

1 

1 

1 

1 

1 

1 

1 

Mission  Preparation 

Aviation  Weather 

c 

C 

Mission  Preparation 

Aircraft  Performance  Data/Limitations 

c 

C 

Mission  Preparation 

CRM  and  Communications 

c 

C 

Mission  Preparation 

Publications 

c 

C 

Mission  Preparation 

Emergency  Equip/IFE  Procedures 

c 

C 

Mission  Preparation 

Departure  and  Arrival  Planning 

c 

C 

Mission  Preparation 

Flight  Checklists  and  Use 

c 

C 

1 

Mission  Preparation 

Computerized  Flight  Planning  Systems 

c 

C 

1 

Mission  Preparation 

Charts  -  Sectional,  Tactical,  Global 

c 

C 

1 

1 

1 

1 

1 

1 

1 

Mission  Preparation 

Mission  Route  Selection  &  Analysis 

c 

C 

Mission  Preparation 

ICAO/FLIP  Procedures 

c 

C 

Communications 

Communications  planning  and  management 

c 

C 

Communications 

Data  Links 

c 

C 

Communications 

Knowledge  of  Airborne  Communication  Systems 

c 

C 

Aircraft  Operations 

Weather  Hazards 

c 

C 

Aircraft  Operations 

Basic  Manual  Navigation 

c 

C 

1 

1 

1 

1 

1 

1 

1 

Aircraft  Operations 

General  Flight  Rules 

c 

C 

Aircraft  Operations 

Low  Level  Flying 

c 

C 

Aircraft  Operations 

Fuel  Planning 

c 

C 

Aircraft  Operations 

Aircraft  Systems  and  Directives 

c 

C 

Aircraft  Operations 

Integrated  Navigation  Systems 

c 

C 

Aircraft  Operations 

Emergency  Procedures 

c 

C 

Aircraft  Operations 

Aviation  Principles 

c 

C 

1 

1 

1 

Aircraft  Operations 

Manual  Flight  Control  Skills 

c 

C 

Aircraft  Operations 

Time  &  Course  Control 

c 

C 

Air  Operations 

Air  Tasking  Orders  (ATO) 

c 

c 

1 

Before  Flight 

VFR  Mission  planning 

c 

c 

1 

1 

Before  Flight 

Exterior  inspection  checks 

Unique 

Unique 

Before  Flight 

Weather  data  for  mission  planning 

C 

C 

1 

Before  Flight 

Appropriate  communications  procedures 

C 

Unique 

1 

Before  Flight 

Operational  data  for  mission  planning 

c 

C 

1 

1 

Before  Flight 

Starting  engines  checks 

c 

Unique 

Before  Flight 

Mission  briefing 

c 

C 

1 

Before  Flight 

Verbal  communication/radio  procedures 

c 

Unique 

1 

Before  Flight 

Map  preparation  for  use  during  flight 

c 

Unique 

1 

1 

1 

Before  Flight 

GPS  position  checks 

c 

Unique 

Before  Flight 

Route  planning  to  destination  &  alternates 

c 

Unique 

Before  Flight 

Pre-flight  clearances 

c 

C 

1 

Before  Flight 

Enroute  altitudes  lAW  FLIP 

c 

C 

1 

Before  Flight 

GCS  instrument  checks 

c 

Unique 

1 

1 

1 

1 

1 

Before  Flight 

Prefiight  checks 

c 

Unique 

Before  Flight 

Before  takeoff  checks 

c 

Unique 

Before  Flight 

Maintenance  logs 

c 

C 

Contact 

Recognize  departure  and  recovery  procedures 

c 

Unique 

Contact 

Controlling  Rate  of  Descent 

c 

Unique 

1 

1 

1 

1 

1 

Contact 

Appropriate  climb  airspeed 

c 

Unique 

Contact 

Use  of  local  area  map  for  orientation 

c 

Unique 

Contact 

Establishing  and  maintaining  altitude 

c 

Unique 

Contact 

Clearing  turns 

c 

Unique 

Contact 

Applicable  in-flight  checks 

c 

Unique 

1 

1 

1 

1 

Contact 

Slow  flight 

c 

Unique 

Contact 

Turns,  climbs,  descents,  as  required 

c 

Unique 

Contact 

Approach  to  field  checks 

c 

Unique 

Contact 

Level  off  checks 

c 

Unique 
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1 

1 

1 

1 

1 

1 

Contact 

Basic  aero  maneuvers 

C 

Unique 

Contact 

Basic  area  orientation 

C 

Unique 

Contact 

Before  descent  checks 

c 

Unique 

Contact 

Current  wind  conditions 

c 

Unique 

Contact 

Automatic  approach  &  landing 

c 

Unique 

Contact 

Touch  &  go  landing 

c 

Unique 

1 

1 

1 

1 

1 

1 

1 

Contact 

Approach  to  landing 

c 

Unique 

Contact 

Go-around  on  final  approach  turn 

c 

Unique 

Contact 

Landing  &  rollout  procedures 

c 

Unique 

Contact 

Airspeed  change,  straight-and-level  as  reguired. 

c 

Unique 

Contact 

Go-around/missed  approach  checks 

c 

Unique 

Contact 

Go-ahead  from  final  approach/flare 

c 

Unique 

Contact 

Post  landing  checks  &  procedures 

c 

Unique 

1 

1 

1 

1 

1 

1 

1 

Contact 

GCS  safety  procedures 

c 

Unique 

Contact 

Flight  line  and  air  discipline 

c 

Unique 

Contact 

Normal  traffic  pattern 

c 

Unique 

Contact 

Final  approach  procedures 

c 

Unique 

Contact 

Traffic  pattern  deconfliction 

c 

Unique 

Contact 

Takeoff,  initial  climb  &  associated  checks 

c 

Unique 

Contact 

Clearing  airspace  in  direction  of  turn 

c 

Unique 

1 

1 

1 

Contact 

Maneuvering  within  assigned  airspace 

c 

Unique 

Contact 

Aircraft  configuration:  Pre-landing  checks 

c 

Unique 

Contact 

Airmanship,  judgment,  &  decision-making  in  aircraft 
(GCS-Situational  awareness) 

c 

Unique 

1 

1 

1 

1 

1 

1 

1 

Contact 

Unusual  attitudes  and  recovery  technigues 

c 

Unique 

Contact 

Stalls  and  recovery  procedures 

c 

Unique 

Contact 

Nomnal  overhead  and  straight-in  patterns,  as 
appropriate 

c 

Unique 

Contact 

Altitude/attitude  control  throughout  flight 

c 

Unique 

Navigation 

Visual  navigation 

c 

Unique 

Navigation 

Comelation  of  aircraft  position  with  map 

c 

Unique 

Navigation 

Map  reading 

c 

Unique 

1 

Navigation 

Calculation  actual  fuel  consumption 

c 

Unique 

1 

1 

1 

1 

1 

Navigation 

Using  visual  landmarks  in  flight  planning 

c 

Unique 

Navigation 

In-flight  navigation  planning 

c 

Unique 

Navigation 

Calculation/compensation  for  in-flight  winds 

c 

Unique 

Navigation 

Time  and  fuel  management 

c 

Unique 

Navigation 

Calculation  of  new  estimated  time  of  arrival  (ETA) 

c 

Unique 

1 

Navigation 

Lost  communlcation/C2  link  procedures 

c 

Unique 

1 

1 

Emergency 

Emergency  conditions 

Unigue 

Unique 

Emergency 

Analyzing  current  situation,  including  systems  for 
possible  emergency 

Unigue 

Unique 

1 

1 

1 

1 

Emergency 

Aircraft  control  during  emergency  conditions 

Unique 

Unique 

Emergency 

Recognition  of  applicable  emergency  procedures 

Unique 

Unique 

Emergency 

Communication/declaration  of  an  emergency  (if 
reguired) 

C 

C 

Emergency 

Recognition  and  proper  response  to  unplanned  lost  C2 
link  events 

C 

Unique 

1 

1 

1 

Emergency 

Land  as  soon  as  conditions  permit 

C 

Unique 

After  Flight 

After  landing  checks 

C 

Unique 

After  Flight 

Completion  flight  time  logs 

C 

C 

1 

After  Flight 

Engine  shutdown  check 

C 

Unique 

1 

After  Flight 

Completion  maintenance  logs 

C 

C 

1 

1 

After  Flight 

All  safety  procedures  for  securing  aircraft 

Unique 

Unique 

After  Flight 

Post  landing  procedures 

Unique 

Unique 

200 


II 

Aircraft  Operations 

Radio  Aid  Navigation 

C 

Unique 

II 

Aircraft  Operations 

Radar  Navigation/Fixing 

C 

Unique 

II 

Before  Flight 

Compute  takeoff  and  landing  data 

c 

C 

II 

Before  Flight 

Clearance  to  taxi 

c 

C 

II 

Before  Flight 

Local  VFR  flight  clearance 

c 

C 

II 

Before  Flight 

Clearance  for  takeoff 

c 

C 

II 

Before  Flight 

ICE-T/ground  speed 

c 

C 

II 

Before  Flight 

Taxiing  to  runway 

c 

Unique 

II 

Before  Flight 

Filing  DD  175/iCAO  1801  (Flight  Plan) 

c 

C 

II 

Before  Flight 

Taxiing  into  takeoff  position 

c 

Unique 

II 

Before  Flight 

Interior  inspection  check 

c 

Unique 

II 

Before  Flight 

Line  up  checks 

c 

Unique 

II 

Before  Flight 

Before  taxi  check 

c 

Unique 

II 

Before  Flight 

Operation  of  navigation  radios 

c 

Unique 

II 

Contact 

Appropriate  climb  per  manuals  (Tech  order  climb) 

c 

Unique 

II 

Contact 

Reguesting  and  receiving  landing  clearance 

c 

C 

II 

Contact 

Basic  departure  procedures 

c 

Unique 

II 

Contact 

Local  breakout  procedures 

c 

Unique 

II 

Contact 

Leveling  off  from  tech  order  climb 

c 

Unique 

II 

Contact 

Closed  pattern 

c 

Unique 

II 

Navigation 

Position  reporting 

c 

Unique 

II 

Navigation 

Usage  of  Pilot  to  Metro  Service  (PMSV),  Air  Traffic 
Information  Service  (ATIS),  and  Pilot  Report  (PIREP) 

c 

C 

II 

Navigation 

In-flight  ciearances 

c 

C 

II 

Navigation 

Interpretation  of  radio  weather  condition  report 

c 

C 

II 

Navigation 

Dead  reckoning  navigation 

c 

Unique 

II 

Navigation 

Navigation  diversions  based  on  weather  reports 

c 

C 

II 

Navigation 

Actual  and  planned  rate  of  fuel  consumption 

c 

Unique 

II 

Navigation 

Comparing  actual  and  planned  groundspeeds 

c 

C 

II 

After  Flight 

Taxiing  clear  of  runway 

c 

Unique 

II 

After  Flight 

Closing  a  flight  plan  with  ATC 

c 

C 

II 

After  Flight 

Taxiing  to  parking 

c 

Unique 

III 

Aircraft  Operations 

Instrument  Flight 

C 

Unique 

III 

III 

III 

III 

III 

III 

III 

Aircraft  Operations 

Instrument  Flight  Procedures 

C 

Unique 

Before  Flight 

Instrument  Flight  Rules  (IFR)  mission  planning 

C 

C 

Before  Flight 

Obtaining  an  IFR  clearance 

C 

C 

Before  Flight 

Operation  of  Air  Traffic  Surveillance  Equipment 
(IFF/SIF/TCAS/Sense  and  Avoid  Sensors) 

C 

Unique 

Instrument 

Partial  panel  instrument  flight 

C 

Unique 

Instrument 

Aircraft  maneuvers  under  instrument  conditions 

C 

Unique 

Instrument 

Recognition  of  improper  nose  low  condition 

C 

Unique 

III 

III 

III 

III 

III 

III 

III 

Instrument 

Course  intercept 

C 

Unique 

Instrument 

Rate  of  intercept 

C 

Unique 

Instrument 

Angle  of  intercept 

C 

Unique 

Instrument 

Recognition  and  recovery  from  unusual  attitudes  under 
instrument  conditions 

C 

Unique 

Instrument 

Operation  of  aircraft  instruments  and  navigation 
equipment 

C 

Unique 

Instrument 

Hazardous/adverse  weather  conditions  in  flight 

C 

Unique 

Instrument 

Weather  phenomena  which  affect  flight 

C 

C 

III 

III 

III 

III 

Instrument 

Establishing  and  maintaining  constant  altitude, 
airspeed,  and  heading  during  instrument  flight 

C 

Unique 

Navigation 

Unfamiliar  field  departure  procedures 

C 

C 

Navigation 

Low  level  navigation 

C 

Unique 

Navigation 

Unfamiliar  field  visual  and  instrument  approach 

procedures 

C 

C 
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IV 

Mission  Preparation 

Global  Flight  Ops  Knowledge 

C 

c 

IV 

Communications 

Satellite  Communications  (SATCOM) 

C 

Unique 

IV 

Aircraft  Operations 

Global  Navigation  Procedures 

C 

Unique 

IV 

Air  Operations 

Search  and  Rescue  (SAR) 

C 

C 

IV 

Instrument 

Auto/instrument  takeoff,  climb,  &  departure  procedures 

C 

Unique 

IV 

Instrument 

Departing  a  holding  pattern 

C 

Unique 

IV 

Instrument 

Instrument  cross  check 

C 

Unique 

IV 

Instrument 

Procedure  turns 

c 

Unique 

IV 

Instrument 

Intercepting  a  heading  at  a  predetermined  angle 

c 

Unique 

IV 

Instrument 

Transitioning  from  MDAto  runway 

c 

Unique 

IV 

Instrument 

Establishing  and  maintaining  appropriate  heading 

c 

Unique 

IV 

Instrument 

ATC/approach  control  clearances 

c 

Unique 

IV 

Instrument 

Determination  of  lead  point 

c 

Unique 

IV 

Instrument 

Standard  instrument  approach  plate  procedures 

c 

Unique 

IV 

Instrument 

Course  interception 

c 

Unique 

IV 

Instrument 

Procedure  turn  airspace 

c 

Unique 

IV 

Instrument 

IFR  navigation 

c 

Unique 

IV 

Instrument 

En  route  descents 

c 

Unique 

IV 

Instrument 

Fix-to-fix  navigation 

c 

Unique 

IV 

Instrument 

Appropriate  Landing  configuration 

c 

Unique 

IV 

Instrument 

Maintaining  selected  course  with  wind  correction 

c 

Unique 

IV 

Instrument 

Descent  gradients 

c 

Unique 

IV 

Instrument 

Knowledge  of  establishing  arc 

c 

Unique 

IV 

Instrument 

Instrument  Meterorological  Conditions  (IMC) 
penetration 

c 

Unique 

IV 

Instrument 

Arc  interception 

c 

Unique 

IV 

Instrument 

ATC  clearances 

c 

C 

IV 

Instrument 

Arc  maintenance 

c 

Unique 

IV 

Instrument 

ATC  procedures 

c 

C 

IV 

Instrument 

Radial  interception  from  arc 

c 

Unique 

IV 

Instrument 

Remaining  within  cleared  airspace 

c 

Unique 

IV 

Instrument 

Holding  /loitering 

c 

Unique 

IV 

Instrument 

Controlling  Rate  of  Descent 

c 

Unique 

IV 

Instrument 

Understanding  holding  instructions 

c 

Unique 

IV 

Instrument 

Instrument  approach  procedures 

c 

Unique 

IV 

Instrument 

Holding  pattern  entry 

c 

Unique 

IV 

Instrument 

Radar  patterns 

c 

Unique 

IV 

Instrument 

Maintaining  position  within  holding  pattern  airspace 

c 

Unique 

IV 

Instrument 

Following  Ground  Controlled  Approach  (GCA) 
controller's  directions 

c 

Unique 

IV 

Instrument 

Wind  analysis  in  holding  pattern  airspace 

c 

Unique 

IV 

Instrument 

Turning  to  directed  headings 

c 

Unique 

IV 

Instrument 

Maintaining  directed  altitudes 

c 

Unique 

IV 

Instrument 

Glide  slope  control 

c 

Unique 

IV 

Instrument 

Maintaining  proper  airspace 

c 

Unique 

IV 

Instrument 

Course  control 

c 

Unique 

IV 

Instrument 

Establishing  proper  holding  configuration 

c 

Unique 

IV 

Instrument 

Transitioning  from  instruments  to  visual  references 

c 

Unique 

IV 

Instrument 

Precision  radar  approach 

c 

Unique 

IV 

Instrument 

Visual  Descent  Point  (VDP) 

c 

Unique 

IV 

Instrument 

Non-precision  radar  approach 

c 

Unique 

IV 

Instrument 

Circling  approach  procedures 

c 

Unique 

IV 

Instrument 

Gyro-out  instrument  pattern 

c 

Unique 

IV 

Instrument 

Missed  approach  procedures 

c 

Unique 

IV 

Instrument 

Half-standard  rate  turns  on  final 

c 

Unique 

IV 

Instrument 

ATC  missed  approach  clearances 

c 

Unique 

IV 

Instrument 

Gyro-out  precision  radar  approach 

c 

Unique 

IV 

Instrument 

Missed  approach  checks 

c 

Unique 

IV 

Instrument 

Corrections  to  aircraft  heading 

c 

Unique 

IV 

Instrument 

Transitioning  from  glide  path  to  runway 

c 

Unique 

IV 

Instrument 

In-flight  IFR  clearance 

c 

C 
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APPENDIX  E:  DETAILED  LOGIC  EOR  QUANTITATIVE 

ANALYSIS 


Justification  for  the  logic  found  in  the  table  was  based  on  research  from  many 
sources,  including:  Naval  Unmanned  Aircraft  Systems  (UAS)  Family  of  Systems  (FoS) 
(Groups  1-5)  Common/Core  Training  Requirements  Study  Brief  [PMA-205,  2009],  a 
thesis  titled  A  Comparative  Analysis  of  the  Army  MQ-8B  Fire  Scout  Vertical  Takeoff 
Unmanned  Aerial  Vehicle  (VTUAV)  and  Navy  MQ-8B  Manpower  &  Training 
Requirements  [Raymer,  2009],  another  thesis  titled  An  Operational  Manpower  Analysis 
of  the  RQ-8  Fire  Scout  Vertical  Take-Off  Unmanned  Aerial  Vehicle  (VTUAV)  [Stracker, 
2007],  the  Naval  Air  Warfare  Center  Aircraft  Division  Fiscal  Year  2010  Customer 
Stabilized  Rates  [NAWCAD,  2009],  a  draft  report  that  was  done  for  PMA-205  by 
MITRE  and  AIR  4.6,  and  discussions  with  AIR  4.6  and  CAPT  Schmidt. 


Category 

Logie 

Number  of  training 
sites 

The  number  of  training  sites  for  the  existing  distributed  sehoolhouse  eoneept  is 
based  on  data  from  the  Navy  Training  System  Plans  for  the  respeetive  programs 
[PMA-205,  2008]  and  [PMA-205,  2007].  The  eommon  sehoolhouse  eoneepts 
utilize  one  training  site. 

Total  number  of 
simulators 

Existing  training  eoneepts  are  assumed  to  have  two  simulators  per  site  to  ensure 
training  eapability  when  one  is  down  for  maintenanee.  This  assumption  is 
based  on  the  Navy  Training  System  Plans  for  the  respeetive  programs  [PMA- 
205,  2008]  and  [PMA-205,  2007].  The  eommon  sehoolhouse  number  of 
simulators  is  notionally  based  on  data  from  the  throughput  of  1 15  total  students 
per  year.  Assuming  60  students  at  one  time  during  a  eourse  of  six  months,  four 
simulators  would  be  needed  to  aeeommodate  periods  of  two  hours  per  simulator 
with  two  students  per  simulator  working  in  teams.  To  more  aeeurately  prediet 
the  numbers  of  simulators  required,  more  detailed  analysis  is  required  on  the 
aetual  training  plan  for  the  BUQs  and  a  more  realistie  throughput  value  per 
week. 

Total  annual 
simulator  O&S  eost 

Assumptions  for  O&S  eosts  were  based  on  the  eoneept  that  the  simulators  will 
need  few  eorreetive  and  preventative  maintenanee  aetions.  The  simulators  are 
assumed  to  be  designed  and  manufaetured  using  a  majority  of  COTS 
eomponents.  The  COTS  eomponents  inelude  proeessors,  memory,  displays, 
keyboards,  traekballs,  ete.  The  reliability  is  assumed  to  be  high  with  little  in  the 
way  of  preventative  maintenanee.  Ineluded  in  the  estimate  were  eosts  for  one 
teehnieian  full  time  at  NAWCAD  FYIO  Civilian  Band  2  rates,  maintenanee 
eosts  to  replaee  defeetive  simulator  eomponents,  software  updates  to  eorreet 
defieieneies  and  ineorporate  improvements,  and  preventative  maintenanee. 
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Category 


Logic 


Total  annual 

courseware 

management 


Total  annual 
infrastructure  cost 


Total  number  of 
instructors 


Total  annual 
instructor  cost 


This  includes  the  costs  involved  to  manage  all  required  courseware  per  year.  A 
single  set  is  comprised  of  all  printed  material,  software,  and  databases.  Using 
best  engineering  judgment  based  on  current  practices  the  JUCCS  cohort 
assumed  that  there  would  be  two  updates  per  year  for  the  courseware.  Two 
updates  are  manageable  and  would  probably  not  interfere  with  pipeline  training 
goals.  A  technician  to  perform  archiving,  maintenance,  and  updates  based  on 
NAWCAD  FYIO  Civilian  Band  2  rates.  Contractor  provided  course 
management,  software  modifications,  computer  based  training,  and  part  task 
training.  The  contractor  support  needs  more  detailed  analysis  and  is  dependent 
on  how  the  training  is  contracted.  If  the  Navy  decided  to  utilize  a  prime 
contractor  for  all  training  instead  of  a  smaller  contractor,  the  costs  would  be 
different. 

The  basis  of  this  estimate  was  calculated  with  values  from  CNATTU  Norfolk 
[Hernandez,  2010].  The  calculations  were  based  on  one  simulator  in  3000  sq  ft 
of  space,  10  Navy  and  Marine  Corps  Internet  (NMCI)  supported  computers  in 
1000  sq  ft  of  classroom  space,  and  both  spaces  being  in  a  controlled 
environment  for  improved  reliability.  The  NMCI  computers  support  is 
estimated  at  approximately  $4,000  per  computer  seat,  per  year.  The 
infrastructure  cost  for  the  space  includes  the  energy  requirements  that  include 
electrical,  HVAC,  and  steam.  The  energy  costs  were  calculated  to  be  $12,800 
per  year.  An  additional  cost  was  calculated  for  Public  Works  to  maintain  the 
space  for  preventative  and  corrective  maintenance  at  $5,000  per  year.  Total 
infrastructure  costs  are  estimated  at  $57,  800  per  site,  per  year.  Estimates  for 
BAMS,  Fire  Scout,  and  the  common  schoolhouse  concepts  were  multiples 
based  on  the  required  number  of  simulators  and  computers.  It  was  estimated 
that  the  number  of  simulators  per  site  for  the  BAMS  and  Fire  Scout  models 
were  two,  doubling  the  infrastructure  costs  from  $57,800  to  $1 15,600.  The 
common  schoolhouse  models  would  require  four  simulators  per  site  and  the  cost 
would  increase  roughly  four  times  to  $231,200. 

The  number  of  instructors  per  site  was  based  on  best  engineering  judgment  by 
the  JUCCS  cohort  after  review  of  NTSPs  and  discussions  with  NAVAIR  AIR 
4.6.  The  BAMS  and  Fire  Scout  programs  are  to  require  six  instructors  per  site 
to  handle  throughput  requirements.  The  instructors  will  probably  have 
collateral  duties  assigned  when  not  training  and  further  analysis  is  required  to 
calculate  the  actual  manpower  requirements.  The  common  schoolhouse 
calculations  by  PMA-205  were  based  on  estimating  double  the  number  of 
BAMS  and  Fire  Scout  instructors  at  a  single  site  to  handle  the  throughput  of  two 
separate,  but  collocated  training  cohorts.  The  JUCCS  approach  calculated  less 
based  on  an  estimated  96  percent  common  training  syllabus.  A  more  accurate 
estimate  is  recommended  for  future  work  on  the  common  approaches. 

The  cost  of  the  instructors  was  based  on  the  NAWCAD  Civilian  Pay  Band  4 
FYIO  rate  that  is  a  professionally  trained  person  with  either  a  BS  or  MS  degree 
and  experience.  If  an  active  duty  instructor  were  utilized  then  a  different  value 
would  need  to  be  calculated. 
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Category 

Logie 

Total  number  of 
support  and 
administration 
personnel 

The  number  of  support  and  administrative  personnel  per  site  was  based  on  best 
engineering  judgment  by  the  JUCCS  eohort  after  review  of  NTSPs  and 
diseussions  with  NAVAIR  4.6.  The  number  of  support  and  administrative 
personnel  ineludes  training,  personnel,  and  maintenanee  seheduling, 
maintaining  training  reeords,  and  other  elerieal  and  support  ftinetions.  The 
eurrent  number  of  support  and  administrative  personnel  for  BAMS  and  Fire 

Seoul  was  predieted  at  nine  per  site  lAW  eurrent  researeh.  The  eommon 
sehoolhouse  estimate  by  PMA-205  was  eight  and  JUCCS  was  four  based  on 
best  engineering  judgment  and  related  literature.  The  JUCCS  eoneept  will 
require  fewer  personnel  due  to  the  eommon  training  elements,  whieh  will  have 
eommon  training  reeords  and  syllabi. 

Total  annual  support 
and  administration 
personnel  eost 

The  eost  of  the  instruetors  was  based  on  the  NAWCAD  Civilian  Pay  Band  2 

FYIO  rate  that  is  a  professionally  administrative  assistant  with  either  an  AA  or 
BA  degree  and  experienee. 

Total  annual  O&S 
eost 

This  is  the  total  annual  eost  to  operate  eaeh  approaeh.  It  takes  into  aeeount  the 
total  number  of  sites,  the  number  of  distinet  UASs  taught  at  eaeh  site,  and  the 
number  of  simulators  at  eaeh  site. 
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APPENDIX  F:  ACROYMNS 


Acronym 

Term 

ADM 

Acquisition  Decision  Memorandum 

AGL 

Above  Ground  Level 

AIAA 

American  Institute  of  Aeronautics  and  Astronautics 

AMP 

Aviation  Mission  Package 

AOC 

Air  Operations  Center 

AOI 

Area  of  Interest 

ASCII 

American  Standard  Code  for  Information  Interchange 

ATC 

Air  Traffic  Control 

ATM 

Air  Traffic  Management 

ATO 

Air  Tasking  Order 

AV 

Air  Vehicle 

AVO 

Air  Vehicle  Operator 

BAMS 

Broad  Area  Maritime  Surveillance 

BRAC 

Base  Realignment  and  Closure 

BUPERS 

Bureau  of  Naval  Personnel 

BUQ 

Basic  UAS  Qualification 

C2 

Command  and  Control 

C4I 

Command,  Control,  Communication,  Computer  &  Intelligence 

C4ISR 

Command,  Control,  Communication,  Computer,  Intelligence, 
Surveillance  and  Reconnaissance 

CAS 

Close  Air  Support 

CBR 

Chemical,  Biological,  and  Radiological 

CBT 

Computer  Based  Training 

CCI 

Command  and  Control  Interface 

CCISM 

Command  and  Control  Interface  Specific  Module 

CDD 

Capability  Development  Document 

CDL 

Common  Data  Link 
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Acronym 

Term 

CJCS 

Chairman  of  the  Joint  Chiefs  of  Staff 

CJCSI 

Chairman  of  the  Joint  Chiefs  of  Staff  Instruetion 

CNO 

Chief  of  Naval  Operation 

CNSF 

Commander  Naval  Surfaee  Eorees 

COCOM 

Combat  Command 

COI 

Contaet  of  Interest 

CONOPS 

Coneept  of  Operations 

CONUS 

Continental  United  States 

COTS 

Commereial  Off  The  Shelf 

CPD 

Capability  Produetion  Doeument 

DEAD 

Destruetion  of  Enemy  Air  Defenses 

DEI 

Data  Eink  Interfaee 

DoD 

Department  of  Defense 

DODAE 

Department  of  Defense  Aequisition  Eramework 

DoN 

Department  ofNavy 

E3 

Electromagnetic  Environmental  Effects 

EFEBD 

Enhanced  Eunctional  Elow  Bloek  Diagram 

EO/IR 

Eleetro-OptieaFInfra-Red 

EW 

Eleetronie  Warfare 

EAA 

Eederal  Aviation  Administration 

EE 

Elight  Eevel 

EOB 

Eorward  Operation  Bases 

EoS 

Eamily  of  Systems 

ESS 

Elight  Serviee  Station 

EY 

Eiscal  Year 

GAO 

Government  Aeeountability  Offiee 

GCS 

Ground  Control  Station 

GIG 

Global  Information  Grid 

GSI 

Ground  Segment  Interfaee 

HCI 

Human  Computer  Interfaee 
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Acronym 

HMD 

HMI 

HSC 

HSM 

lAA 

ICOM 

IDEF 

IFF 

IOC 

IPR 

IPT 

ISR 

JCS 

JCIDS 

JFC 

JIPT 

IMPS 

JMQ 

JMTF 

JPATS 

JROC 

JSF 

JUAS  COE 

JUCAS 

JUCCS 

JUMTS 

KFOR 

KPP 

KSA 

FCC 


Term 

Helmet  Mounted  Display 

Human-Maehine  Interfaee 

Helieopter  Sea  Combat 

Helieopter  Marine  Strike 

Ineident  Awareness  and  Assessment 

Inputs,  Controls,  Outputs,  and  Measures 

Integration  Definition  for  Funetional  Modeling 

Identifieation  Friend  or  Foe 

Initial  Operational  Capability 

Interim  Projeet  Reviews 

Integrated  Produet  Team 

Intelligence,  Surveillanee,  and  Reconnaissance 

Joint  Chiefs  of  Staff 

Joint  Capabilities  Integration  Development  System 

Joint  Forees  Commander 

Joint  Integrated  Produet  Team 

Joint  Mission  Planning  System 

Joint  Mission  Qualifieation 

Joint  Mission  Task  Fist 

Joint  Primary  Air  Training  System 

Joint  Requirements  Oversight  Council 

Joint  Strike  Fighter 

Joint  Unmanned  Aireraft  Systems  Center  of  Exeellenee 
Joint  Unmanned  Combat  Air  System 

Joint  UAS  Common  Control  Station  -  Team  name  for  this  Cohort 

Joint  UAS  Minimum  Training  Standards 

Kosovo  Forces 

Key  Performance  Parameter 

Knowledge  Skills  and  Abilities 

Fife  Cyele  Costs 


209 


Acronym 

Term 

LCS 

Eittoral  Combat  Ship 

LOI 

Eevel  of  Interoperability 

LOS 

Eine  of  Sight 

LRE 

Eaunch  &  Recovery  Elements 

MBSE 

Model  Based  Systems  Engineering 

MC 

Mission  Commander 

MESF 

Maritime  Expeditionary  Seeurity  Force 

MIECON 

Military  Construetion 

MMA 

Multi-Mission  Maritime  Aircraft 

MMH 

Maintenance  Man-Hours 

MOB 

Main  Operating  Base 

MPO 

Mission  Payload  Operator 

MPRE 

Maritime  Patrol  And  Reconnaissanee  Force 

MSL 

Mean  Sea  Eevel 

MSRON 

Maritime  Expeditionary  Seeurity  Squadron 

MSSE 

Masters  of  Systems  Engineering 

MED 

Mission  Training  Device 

MTT 

Mobile  Training  Team 

MTTR 

Mean  Time  To  Repair 

MUT 

Manned-Unmanned  Teaming 

NAS 

Naval  Air  Station 

NASA 

National  Aeronautics  and  Space  Administration 

NATO 

North  Atlantie  Treaty  Organization 

NAVAIR 

Naval  Air  Systems  Command 

NDIA 

National  Defense  Industrial  Assoeiation 

NECC 

Navy  Expeditionary  Combat  Command 

NOTAM 

Notice  to  Airmen 

NPS 

Naval  Postgraduate  School 

NTSP 

Navy  Training  System  Plan 

O&S 

Operations  and  Sustainment 
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Acronym 

Term 

0PM 

Office  of  Personnel  Management 

OSCE 

Organization  for  Security  and  Cooperation  in  Europe 

OSD 

Office  of  the  Secretary  of  Defense 

OSGCS 

One  System  Ground  Control  Station 

OTH 

Over  the  Horizon 

PBS 

Performance  Based  Specification 

PDA 

Personal  Data  Assistant 

PEO 

Program  Executive  Office 

PEO  (U&W) 

Program  Executive  Office  Unmanned  Aviation  and  Strike 
Weapons 

PID 

Positive  Identification 

PM 

Project  Manager 

PMA-205 

NAVAIR  Training  Systems  Program  Office 

PMA-262 

NAVAIR  Persistent  Maritime  UAS  Program  Office 

PMA-263 

NAVAIR  Small  Tactical  UAS  Program  Office 

PMA-266 

NAVAIR  Multi-Mission  Tactical  UAS  Program  Office 

PMA-268 

NAVAIR  Unmanned  Combat  Air  System  Program  Office 

R&D 

Research  and  Development 

R&M 

Reliability  and  Maintainability 

RE 

Radio  Erequency 

RTSA 

Reconnaissance,  Surveillance,  and  Target  Acquisition 

S&l  IPT 

Standards  and  Interoperability  IPT 

SA 

Situational  Awareness 

SAR 

Synthetic  Aperture  Radar 

SATCOM 

Satellite  Communication 

SE 

Systems  Engineering 

SEAD 

Suppression  of  Enemy  Air  Defenses 

SIGINT 

Signal  Intelligence  Gathering 

SINCGARS 

Single  Channel  Ground  and  Airborne  Radio  System 

STANAG 

Standard  Agreement 
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Acronym 

Term 

STUAS 

Small  Tactical  Unmanned  Air  System 

TCAS 

Traffic  Collision  Avoidance  System 

TCDL 

Tactical  Common  Data  Link 

TCS 

Tactical  Control  Station 

TIMS 

Training  Integration  Management  System 

TOI 

Target  of  Interest 

TST 

Time  Sensitive  Targeting 

TIP 

Tactics,  Techniques,  and  Procedures 

TYCOM 

Type  Commander 

U&W 

Unmanned  Aviation  and  Weapons 

UAS 

Unmanned  Air  or  Aircraft  Systems 

UASFCS 

UAS  Flight  Crew  Skills 

UASMCS 

UAS  Mission  Crew  Skills 

UAV 

Unmanned  Aerial  Vehicle 

UCAS 

Unmanned  Combat  Air  System 

UCS 

UAV  Control  System 

UGV 

Unmanned  Ground  Vehicle 

UHF 

Ultra  High  Frequency 

UMS 

Unmanned  Maritime  Systems 

USAF 

United  States  Air  Force 

USD(AT&L) 

Under  Secretary  of  Defense  of  Acquisition,  Technology,  and 
Logistics 

USFFC 

United  States  Fleet  Forces  Command 

USJFCOM 

United  States  Joint  Forces  Command 

USMC 

United  States  Marine  Corps 

USN 

United  States  Navy 

VFR 

Visual  Flight  Rules 

VSM 

Vehicle  Specific  Module 

VTUAV 

Vertical  Take-off  and  Land  Tactical  UAV 

WBT 

Web-Based  Training 
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